[infinispan-dev] MyRpcDispatcher

[Galder Zamarreno]

No, there aren't. I ended up going down the route of having a cache for the Hot Rod view information. It was actually a lot simpler since nodes had to share Hot Rod view information.

----- "Bela Ban" <bela at jboss.com> wrote:

> Are there any unit tests you've written ?
> 
> galder at jboss.org wrote:
> > Hi Paul,
> >
> > I'm not sure what method Bela is talking about. The only thing I
> suggested is having some kind of scope getter method that allows
> updating the handlers map.
> >
> > Paul, let me know when you've committed this stuff and I'll try it
> out. I'm also investigating Bela's suggestion of having a separate
> cache.
> >
> > Cheers,
> >
> > ----- "Paul Ferraro" <paul.ferraro at redhat.com> wrote:
> >
> >   
> >> Galder,
> >>
> >> To which method is Bela referring?
> >>
> >> Otherwise, I'm ready to check in the org.jgroups.blocks.mux
> package.
> >> There is a small change required in
> >> MessageDispatcher.setChannel(...):
> >>
> >>   channel.setUpHandler(prot_adapter);
> >>
> >> needs to be replaced by:
> >>
> >>   if (channel.getUpHandler() == null)
> >>     channel.setUpHandler(prot_adapter);
> >>
> >> This is need to prevent each new RpcDispatcher/MessageDispatcher
> from
> >> overwriting the preexisting multiplexing UpHandler.
> >> I can't envision this breaking any existing use case, but I wanted
> to
> >> verify before committing.
> >>
> >> So, to review, usage will now look like:
> >>
> >> Channel c = new JChannel(...);
> >>
> >> // RpcDispatcher d = new RpcDispatcher(c, null, null, target);
> >> // c.setUpHandler(new MuxUpHandler(d.getProtocolAdapter());
> >>
> >> c.setUpHandler(new MuxUpHandler());
> >>
> >> RpcDispatcher d1 = new MuxRpcDispatcher((short) 1, c, null, null,
> >> target);
> >> RpcDispatcher d1 = new MuxRpcDispatcher((short) 2, c, null, null,
> >> target);
> >>
> >> c.connect(...);
> >>
> >> Paul
> >>
> >> On Mon, 2010-04-12 at 13:16 +0200, Bela Ban wrote:
> >>     
> >>> I understand all of the new code is in the new package 
> >>> org.jgroups.blocks.scope. If that's the case, I suggest add and
> >>>       
> >> commit 
> >>     
> >>> your changes so you can experiment with them.
> >>>
> >>> I also recall Galder needed to change some method from private to
> 
> >>> protected, why don't you go ahead and do this too ?
> >>>       
> >> <snip>
> >>     
> 
> -- 
> Bela Ban
> Lead JGroups / JBoss Clustering team
> JBoss - a division of Red Hat