[
https://issues.jboss.org/browse/JGRP-1413?page=com.atlassian.jira.plugin....
]
Bela Ban updated JGRP-1413:
---------------------------
Summary: Pass bundled messages up together as MSG_LIST event (was: Pass bundled
messages up together as MSG_BUNDLE event)
Description:
When we receive a message bundle, e.g. 10 (multicast or unicast) messages at the transport
(if bundling is enabled), then we currently pass each message up separately:
List<Message> list;
for(Message msg: list)
up_prot.up(new Event(Event.MSG, msg));
NAKACK then adds every message and calls removeMany() after that. Both the addition and
the removal acquire locks, plus, most of the time - removeMany() will only remove 1
message !
It would be better to send the message bundle (in the example above, consisting of 10
messages) up as *one* event, e.g:
List<Message> list;
up_prot.up(new Event(Event.MSG_LIST, list));
NAKACK, NAKACK2, UNICAST and UNICAST2 would have to handle this new event type.
For example, NAKACK2 would call a (new) method RingBuffer.addAndRemoveMany(), which adds
all 10 messages and removes N messages using the same lock, ie. lock acquisition would be
done only once !
Above the reliable retransmission protocols (currently NAKACK, NAKACK2, UNICAST and
UNICAST2), messages would be passed up one-by-one. Later, we might look into whether it
makes sense to pass up message bundles *above* the reliable retransmission protocols...
was:
When we receive a message bundle, e.g. 10 (multicast or unicast) messages at the transport
(if bundling is enabled), then we currently pass each message up separately:
List<Message> list;
for(Message msg: list)
up_prot.up(new Event(Event.MSG, msg));
NAKACK then adds every message and calls removeMany() after that. Both the addition and
the removal acquire locks, plus, most of the time - removeMany() will only remove 1
message !
It would be better to send the message bundle (in the example above, consisting of 10
messages) up as *one* event, e.g:
List<Message> list;
up_prot.up(new Event(Event.MSG_BUNDLE, list));
NAKACK, NAKACK2, UNICAST and UNICAST2 would have to handle this new event type.
For example, NAKACK2 would call a (new) method RingBuffer.addAndRemoveMany(), which adds
all 10 messages and removes N messages using the same lock, ie. lock acquisition would be
done only once !
Above the reliable retransmission protocols (currently NAKACK, NAKACK2, UNICAST and
UNICAST2), messages would be passed up one-by-one. Later, we might look into whether it
makes sense to pass up message bundles *above* the reliable retransmission protocols...
Pass bundled messages up together as MSG_LIST event
---------------------------------------------------
Key: JGRP-1413
URL:
https://issues.jboss.org/browse/JGRP-1413
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.1
When we receive a message bundle, e.g. 10 (multicast or unicast) messages at the
transport (if bundling is enabled), then we currently pass each message up separately:
List<Message> list;
for(Message msg: list)
up_prot.up(new Event(Event.MSG, msg));
NAKACK then adds every message and calls removeMany() after that. Both the addition and
the removal acquire locks, plus, most of the time - removeMany() will only remove 1
message !
It would be better to send the message bundle (in the example above, consisting of 10
messages) up as *one* event, e.g:
List<Message> list;
up_prot.up(new Event(Event.MSG_LIST, list));
NAKACK, NAKACK2, UNICAST and UNICAST2 would have to handle this new event type.
For example, NAKACK2 would call a (new) method RingBuffer.addAndRemoveMany(), which adds
all 10 messages and removes N messages using the same lock, ie. lock acquisition would be
done only once !
Above the reliable retransmission protocols (currently NAKACK, NAKACK2, UNICAST and
UNICAST2), messages would be passed up one-by-one. Later, we might look into whether it
makes sense to pass up message bundles *above* the reliable retransmission protocols...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira