[
https://issues.jboss.org/browse/JGRP-1816?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1816:
--------------------------------
This is an alternative to {{JChannel.setDiscardOwnMessages()}}:
* The {{DONT_LOOPBACK}} flag can be set *per message*, so it's much more flexible
* The dropping of the message happens at the transport level, not at the JGroups level, so
we cut down on unneeded processing
Message: add flag DONT_LOOPBACK
-------------------------------
Key: JGRP-1816
URL:
https://issues.jboss.org/browse/JGRP-1816
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
When flag {{DONT_LOOPBACK}}, then multicast messages ({{dest}} == null) are not looped
back up the stack. This can be useful in some cases, e.g. discovery:
* A multicasts a discovery request
* A gets the discovery request and adds information shipped with it (A's
logical-physical address mapping and logical name) to its local cache(s)
* A sends a discovery response to itself
* A gets the discovery response and adds its information *again*
--> Because the information was already present, it doesn't need to be added, *but
was added 2 more times* !
--> This unneeded processing costs threads from the pool, processing power, locks etc
SOLUTION:
* When sending a multicast message we loop it back up and then multicast it. When
received by the sender, we drop it.
* We now don't even loop back the message if DONT_LOOPBACK is set
--
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