]
Bela Ban resolved JGRP-1084.
----------------------------
Resolution: Won't Fix
MessageDispatched to have marshalling callback after real_dest have
been calculated
-----------------------------------------------------------------------------------
Key: JGRP-1084
URL:
https://issues.jboss.org/browse/JGRP-1084
Project: JGroups
Issue Type: Feature Request
Reporter: Galder ZamarreƱo
Assignee: Vladimir Blagojevic
Priority: Minor
Fix For: 3.3
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call
should stay local, so ISPN should need to do this calculation again, it's wasteful
code. The real fix would be to somehow be able to do marshalling only if the code in
MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown
above where we can invoke marshalling?
--
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: