[rabbitmq-discuss] TCP timeouts

[Holger Hoffstätte]

Non-Erlang-related-Java-is-funny-offtopic warning!

> David.Corcoran at edftrading.com wrote:
>> It looks like you were right about the java version. Running in java
>> 1.5.0.15 doesn't work. Running in java-6-openjdk or java-6 (1.6.0.06) works
>> fine. I think it's a bug, perhaps related to this:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6383015
> 
> Interesting. Yes, that looks like it would explain the behaviour you saw.

A very interesting anomaly indeed, especially considering that it only 
seems to affect 1.5, not 1.4 or 1.6. However, as far as I can tell this 
behaviour can only occur with one CPU. I bet that David's test will run 
fine when he enables more cores and/or starts running "real" code in the 
process() method - meaning: code that creates garbage and doesn't just 
repeatedly busy-waits on a native method, which accidentally must also 
obey special synchronization rules. David, could you please try this if it 
is not too inconvenient?
Ideally process() should run in a sepate thread anyway so that the 
controlling thread can properly wait for a result or - more importantly - 
cancel the computation if necessary.

> In the absence of even the most basic fairness guarantees from the jvm - 
> such as no starvation - asking programmers to insert Thread.yield() in 
> strategic places is about he best you can do.

Unfortunately this might not have the effect that one expects, as yield() is:

- free to be implemented as no-op; I think that at one point the server VM 
  explicitly optimized it away

- implemented differently in various versions of the JVM, both client and 
server

- dependent on OS- and GC-algorithm: for a fun time, search for "yield" in 
http://openjdk.neojava.org/hotspot/xref/src/share/vm/runtime/globals.hpp

- yielding native threads might not even work according to the general 
expectations of either apps or the JVM: until recently (or since then, 
depending on point of view) Linux didn't really yield() "correctly" 
(according to POSIX), resulting in..yet another magic kernel flag! 
Hilarious discussion in: http://kerneltrap.org/Linux/CFS_and_sched_yield

IMHO sprinkling yield() or sleeps() across a codebase has a definite 
"magic pixie dust" smell, and should be avoided at all costs. The JCIP 
book explains all this in chapter 10.3.1 ("Starvation") and pretty much 
only recommends yields/sleep to create artificial delays when debugging 
(to create races).

Besides, LockSupport.parkNanos() sounds much more advanced anyway. :-)

-h