[infinispan-dev] MyRpcDispatcher

[Brian Stansberry]

Good point on "shared".

I laughed off "multiplexer" in my last post 'cause I thought it would 
give you a stroke!

Resurrecting it with a new  meaning is ok by me (multiplexing is a 
pretty general concept) except I'm a bit concerned the legacy usage is 
not quite dead yet. Specifically in the 
ChannelFactory.createMultiplexerChannel methods and the JBC (hopefully 
not Infinispan) Configuration where there are properties like 
getMuxStackName.

OK, checked Infinispan and as expected there's no mention of "mux" 
anywhere. And the AS ChannelFactory for years has been documented as not 
returning a MuxChannel from createMultiplexerChannel. So, I don't have a 
concern about reusing the Multiplexer term.

On 04/12/2010 08:08 AM, Bela Ban wrote:
> Shared also has a connotation in JGroups, maybe MultiplexedUpHandler ?
> MuxUpHandler ? The latter 2 would give a bad word a new (hopefully
> better !) meaning...
>
> Brian Stansberry wrote:
>> We need to think of another word besides "scope" for this, since it
>> has a completely separate meaning elsewhere in JGroups.
>>
>> Multiplexer? Just kidding ;-)
>>
>> Shared/shareable? That seems reasonable in package/class names, but
>> not so good for the short "scope" param/field. Maybe "scope" is ok for
>> the param/field if we can come up with something else for the
>> package/class names; by the time you are thinking about variables the
>> package/class names have given you a clue what you're looking at.
>>
>> On 04/12/2010 06:16 AM, 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 ?
>>>
>>> Paul Ferraro wrote:
>>>> I've modified Bela's existing sample code to address the issues Brian
>>>> and I discussed below. Here's a summary of the changes:
>>>>
>>>> * Refactored pieces into separate classes with nicer names
>>>> * ScopedRpcDispatcher registers its scope with a ScopedUpHandler
>>>> * Added ScopeUpHandler deregistration on ScopedRpcDispatcher.stop().
>>>> * ScopedUpHandler accepts an optional default handler, which will be
>>>> triggered for non-message events or messages with no scope header
>>>> * ScopedUpHandler returns NoHandlerForScope object if message is
>>>> received for an unknown scope (e.g. its handler was not yet registered
>>>> or was already deregistered)
>>>> * Automatically adds RspFilter to RequestOptions that rejects
>>>> NoHandlerForScope responses, decorating any existing filter, if
>>>> necessary.
>>>> * Added ScopedMessageDispatcher analogue
>>>>
>>>> So, usage would look like:
>>>>
>>>> Channel c = new JChannel(...);
>>>>
>>>> ScopedUpHandler h = new ScopedUpHandlerImpl();
>>>>
>>>> ScopedRpcDispatcher d1 = new ScopedRpcDispatcher((short)1, h, c, null,
>>>> null, target1);
>>>> ScopedRpcDispatcher d2 = new ScopedRpcDispatcher((short)2, h, c, null,
>>>> null, target2);
>>>>
>>>> // This must be set after all rpc dispatchers are created
>>>> c.setUpHandler(h);
>>>> c.connect(...);
>>>>
>>>>
>>>> This will also work in conjunction with a standard rpc dispatcher:
>>>>
>>>> Channel c = new JChannel(...);
>>>>
>>>> RpcDispatcher d = new RpcDispatcher(c, null, null, target);
>>>> ScopedUpHandler h = new ScopedUpHandlerImpl(d.getProtocolAdapter());
>>>>
>>>> ScopedRpcDispatcher d1 = new ScopedRpcDispatcher((short)1, h, c, null,
>>>> null, target1);
>>>> ScopedRpcDispatcher d2 = new ScopedRpcDispatcher((short)2, h, c, null,
>>>> null, target2);
>>>>
>>>> c.setUpHandler(h);
>>>> c.connect(...);
>>>>
>>>>
>>>> I've attached the changes in the form of a patch to JGRP-1177.
>>>> Comments are welcome.
>>>>
>>>> Paul
>>>>
>>>>
>>>
>>
>>
>


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat