[
http://jira.jboss.com/jira/browse/JGRP-540?page=comments#action_12366863 ]
Vladimir Blagojevic commented on JGRP-540:
------------------------------------------
An easier way to reproduce this problem very frequently is to remove sleep
(Util.sleepRandom(200)) in the receiver used in MultiplexerTest#testOrdering test method.
Test fails for me every time after the sleep is removed.
After further investigation it indeed seems that thread pool is indeed the culprit and
more specifically the problem is I believe in SynchronousQueue hand off mechanism in
thread pool. This hand off mechanism is inherently by its own design violating FIFO order
and should be replaced by LinkedBlockingQueue. After the change testOrdering test was
passing consistently. However, that introduced failures in MultiplexerConcurrentTest. I
then realized that in order to have concurrency we need for MultiplexerConcurrentTest to
pass and ordering we need to use LinkedBlockingQueue but we also need to increase number
of core threads in thread pool. After this change all tests were passing consistently.
Multiplexer: ordering issue
---------------------------
Key: JGRP-540
URL:
http://jira.jboss.com/jira/browse/JGRP-540
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.5
Sometimes messages from the same sender are not delivered in the correct order, the test
that shows this (happens infrequently) is MultiplexerTest.testOrdering().
When disabling the Multiplexer thread pool (-Djgroups.mux.enabled=false), everything
works fine, so I suspect this is a thread pool issue in the Multiplexer
(FIFOMessageQueue).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira