[
https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin....
]
Radim Vansa commented on JGRP-1711:
-----------------------------------
As the implementation of incoming messages delay would be more complicated, I think that
implementing outcoming delay could be sufficient. Anyway, I can't distinguish where
the message got delayed on network. What was the reason to provide both delays in DELAY?
DELAY2: Do not keep the thread waiting
--------------------------------------
Key: JGRP-1711
URL:
https://issues.jboss.org/browse/JGRP-1711
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.4
Reporter: Radim Vansa
Assignee: Bela Ban
Priority: Minor
Current version of the DELAY protocol is rather simplistic - the thread is just put to
sleep for some period of time. However, this does not reflect the network delay very well
as it consumes the thread during the latency period.
As the protocol should be usually placed just above TP, I'd suggest that for
outcoming delay, the message/event should be placed into priority queue and another
dedicated thread should pass it down after the latency period.
For the incoming messages, we'd probably need a way to access TP's threadpools,
and to find out where the currently executing thread belongs. Then, the message/event
would also use priority queue and take a thread from the same threadpool in order to
deliver it to upper layers.
Another feature of this new implementation of delay protocol would be to allow constant
latency, or rather specify the latency interval (from - to: currently from is always 0).
--
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