[ 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... -- 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

[ https://issues.jboss.org/browse/JGRP-1413?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1413. ---------------------------- Resolution: Deferred The amount of code change required doesn't warrant inclusion of this JIRA, especially given that performance is not affected. Until there is a better approach, this JIRA is deferred indefinitely. -- 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