[
https://issues.jboss.org/browse/JGRP-1732?page=com.atlassian.jira.plugin....
]
Bela Ban edited comment on JGRP-1732 at 1/7/14 2:46 AM:
--------------------------------------------------------
OK, the reason is that UNICAST3 corrects the above scenario quickly (within xmit_interval
ms), whereas NAKACK2 has to wait until the next stability message (STABLE), which is
seconds by default.
Reverting the change for NAKACK2.
was (Author: belaban):
OK, the reason is that UNICAST3 corrects the above scenario quickly (within
xmit_interval ms), whereas NAKACK2 has to wait until the next stability message (STABLE),
which is seconds by default.
Reverting the changr for NAKACK2.
UNICAST/NAKACK: threads from the internal thread pool should not do
work stealing
---------------------------------------------------------------------------------
Key: JGRP-1732
URL:
https://issues.jboss.org/browse/JGRP-1732
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and
internal) add messages to the table, then grab as many (ordered) messages as possible from
the table and pass them up.
This could lead to the case where an internal thread passes up regular or OOB messages,
which might block. There's a (small) chance that this exhausts the internal thread
pool.
Internal threads should therefore never block, and never steal work from other thread
pools.
SOLUTION:
* An internal thread only adds the message to the table and passes it up if in order
* If the internal message is OOB, it is passed up and then the thread returns
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira