[rabbitmq-discuss] TCP timeouts
holger at wizards.de
Fri May 9 13:07:12 BST 2008
> David.Corcoran at edftrading.com wrote:
>> It looks like you were right about the java version. Running in java
>> 188.8.131.52 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:
> 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
- dependent on OS- and GC-algorithm: for a fun time, search for "yield" in
- 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. :-)
More information about the rabbitmq-discuss