[jboss-jira] [JBoss JIRA] Commented: (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated

Galder Zamarreno (JIRA) jira-events at lists.jboss.org
Tue Jan 26 10:56:20 EST 2010


    [ https://jira.jboss.org/jira/browse/JGRP-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12508419#action_12508419 ] 

Galder Zamarreno commented on JGRP-1084:
----------------------------------------

Note that CommandAwareDispatcher removes the local address after the request has been marshalled, so we still need ISPN-237 in place, otherwise single owner scenarios where target is local would still be marshalled. CommandAwareDispatcher probably needs enhancing so that marshalling only happens when we know for sure that the call will go remote. 

Right now, the first thing CommandAwareRpcDispatcher$ReplicationTask.call() does is the marshalling and if ISPN-237 was not in place, it'd be trying to marshall something wastefully. I don't know right now whether there're other scenarios where we might be marshalling wasterfully. Manik/Mircea, since you've been working on the CommandAwareRpcDispatcher lately, you might wanna check this out and make sure marshalling is moved to part of call() code where you know for sure that the call will go remotely.

> MessageDispatched to have marshalling callback after real_dest have been calculated
> -----------------------------------------------------------------------------------
>
>                 Key: JGRP-1084
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1084
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Galder Zamarreno
>            Assignee: Vladimir Blagojevic
>            Priority: Minor
>             Fix For: 2.10
>
>
> 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 contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the jboss-jira mailing list