Re: JGroups Shared Transport support in JBC
by Brian Stansberry
Sorry Tim, I'd meant to include you on this thread from the start. :(
We were having a discussion of how to handle the difference between a
JGroups JChannel w/ a shared transport (new in 2.6.2) and the old
multiplexer MuxChannel.
If you call ChannelFactory.createMultiplexerChannel() the return type is
Channel, but the code actually returns the MuxChannel implementation
class. Which is reasonable; the name of the method implies the
multiplexer will be used.
But, a shared transport JChannel is actually a much better solution to
JGroups resource sharing. So, question is how to get a shared transport
JChannel into users' hands.
1) Have them specifically ask for a JChannel by calling
ChannelFactory.createChannel(String) instead of
ChannelFactory.createMultiplexerChannel(). Puts the issue back in the
user service; e.g. JBC might add a config property to help it determine
if a call to createMultiplexerChannel() or createChannel() is the
desired way to go. Or maybe just switch to createChannel().
2) Have the createMultiplexerChannel() method internally decide whether
to return a MuxChannel or a shared transport JChannel.
Due to the late date this came up, my plan for AS 5 was #2.
JBMESSAGING-1244 is a problem with that plan, but I see you have a JBM
1.4.1.BETA2 Fix Version on that, so I think it's OK.
#1 isn't workable yet; it requires a minor change in JGroups that won't
be out until 2.6.3. After I found JBMESSAGING-1244, I pinged Bela/Manik
to see if it could be done quickly in case JBMESSAGING-1244 was
something that wouldn't get done in time for AS 5. Sounds like it's not
an issue.
Tim Fox wrote:
>
>
> Manik Surtani wrote:
>> Is Tim even on this list?
>
> On jbosscache-dev - no I'm not
>
> Can someone recap?
>
>>
>> On 4 Mar 2008, at 11:58, Bela Ban wrote:
>>
>>> Releasing 2.6.3 is not really feasible, as I've just released 2.6.2.
>>> So, if the change in JBC and JBM is minor (which I think it is), then
>>> I'd appreciate your guys fixing this.
>>> Cheers,
>>>
>>> Manik Surtani wrote:
>>>> And I could implement this in JBC 2.1.0.GA easily enough, but if
>>>> there is a viable workaround I'd rather leave this for 2.2.0 given
>>>> current timeframes.
>>>>
>>>>
>>>> On 4 Mar 2008, at 07:14, Bela Ban wrote:
>>>>
>>>>>
>>>>>
>>>>> Brian Stansberry wrote:
>>>>>> Being able to handle this in JBC 2.1.0 is a bit more of an issue
>>>>>> due to a bug in the way JBM handles a Channel.connect() call
>>>>>> (http://jira.jboss.com/jira/browse/JBMESSAGING-1244). The bug
>>>>>> basically means JBM will fail if it calls
>>>>>> ChannelFactory.createMultiplexerChannel() and the call doesn't
>>>>>> return a MuxChannel. So, my intended approach for AS 5 (override
>>>>>> createMultiplexerChannel()and return a regular JChannel if it's
>>>>>> configured for shared transport) breaks JBM.
>>>>>>
>>>>>> Maybe they'll get JBMESSAGING-1244 fixed in time for AS 5; maybe not.
>>>>>
>>>>> I certainly hope so, sounds like a small change (use a JChannel
>>>>> type rather than a MuxChannel (extends JChannel))...
>>>>>
>>>>>> If we can get a JGroups 2.6.3
>>>>>
>>>>> Another release, so soon after 2.6.2 ? Only if absolutely
>>>>> necessary. Seems to me that Tim can fix his stuff much more
>>>>> quickly... In any case, let me know, I need a few days to get a
>>>>> 2.6.3 out (including fixing the NPE you opened).
>>>>>
>>>>>> and JBC 2.1.0.GA able to call ChannelFactory.createChannel(), then
>>>>>> I can just let JBM get a MuxChannel.
>>>>>
>>>>> This is possible in 2.6.3 by which feature/bug I implemented ?
>>>>>
>>>>> --
>>>>> Bela Ban
>>>>> Lead JGroups / Clustering Team
>>>>> JBoss - a division of Red Hat
>>>>
>>>> --
>>>> Manik Surtani
>>>> Lead, JBoss Cache
>>>> manik(a)jboss.org
>>>> msurtani(a)redhat.com
>>>>
>>>>
>>>>
>>>
>>> --
>>> Bela Ban
>>> Lead JGroups / Clustering Team
>>> JBoss - a division of Red Hat
>>>
>>
>> --
>> Manik Surtani
>> Lead, JBoss Cache
>> manik(a)jboss.org
>> msurtani(a)redhat.com
>>
>>
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
18 years, 3 months
Re: JGroups Shared Transport support in JBC
by Bela Ban
Releasing 2.6.3 is not really feasible, as I've just released 2.6.2. So,
if the change in JBC and JBM is minor (which I think it is), then I'd
appreciate your guys fixing this.
Cheers,
Manik Surtani wrote:
> And I could implement this in JBC 2.1.0.GA easily enough, but if there
> is a viable workaround I'd rather leave this for 2.2.0 given current
> timeframes.
>
>
> On 4 Mar 2008, at 07:14, Bela Ban wrote:
>
>>
>>
>> Brian Stansberry wrote:
>>> Being able to handle this in JBC 2.1.0 is a bit more of an issue due
>>> to a bug in the way JBM handles a Channel.connect() call
>>> (http://jira.jboss.com/jira/browse/JBMESSAGING-1244). The bug
>>> basically means JBM will fail if it calls
>>> ChannelFactory.createMultiplexerChannel() and the call doesn't
>>> return a MuxChannel. So, my intended approach for AS 5 (override
>>> createMultiplexerChannel()and return a regular JChannel if it's
>>> configured for shared transport) breaks JBM.
>>>
>>> Maybe they'll get JBMESSAGING-1244 fixed in time for AS 5; maybe not.
>>
>> I certainly hope so, sounds like a small change (use a JChannel type
>> rather than a MuxChannel (extends JChannel))...
>>
>>> If we can get a JGroups 2.6.3
>>
>> Another release, so soon after 2.6.2 ? Only if absolutely necessary.
>> Seems to me that Tim can fix his stuff much more quickly... In any
>> case, let me know, I need a few days to get a 2.6.3 out (including
>> fixing the NPE you opened).
>>
>>> and JBC 2.1.0.GA able to call ChannelFactory.createChannel(), then I
>>> can just let JBM get a MuxChannel.
>>
>> This is possible in 2.6.3 by which feature/bug I implemented ?
>>
>> --
>> Bela Ban
>> Lead JGroups / Clustering Team
>> JBoss - a division of Red Hat
>
> --
> Manik Surtani
> Lead, JBoss Cache
> manik(a)jboss.org
> msurtani(a)redhat.com
>
>
>
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat
18 years, 3 months
JGroups Shared Transport support in JBC
by Brian Stansberry
In JGroups 2.6.2, the JGroups team is introducing the shared transport
as a (superior) alternative to the multiplexer. Want to touch off a
discussion of how to take advantage of that in JBC.
Currently in JBC, user can inject a ChannelFactory into their cache
configuration, and configure a MultiplexerStack (string). If both are
set, JBC calls ChannelFactory.createMultiplexerChannel(), which returns
a MuxChannel.
So, how can JBC get a regular JChannel w/ a shared transport instead of
a MuxChannel? Couple solutions come to mind:
1) Add a configuration property ChannelStack to the JBC config. If
present, JBC calls JChannelFactory.createChannel(String) instead of
ChannelFactory.createMultiplexerChannel(). Basically, the user
indicates what they want by how they configure. This IMHO is the
cleanest and simplest.
Problem is the createChannel(String) method is not exposed in the
ChannelFactory interface; it's only in the JChannelFactory
implementation. JBC needs to use the interface. Bela, can this method
be added to the interface in 2.6.2?
If it can be, any thoughts switching JBC 2.1 to use 2.6.2 and adding the
property?[1]
2) A hackier alternative is to override the behavior of
createMulitiplexerChannel so it checks the specified protocol stack
config and returns a regular JChannel if the stack uses a shared
transport; a MuxChannel otherwise. AS 5 already uses a custom
ChannelFactory impl (for other reasons); doing this is how I plan to get
shared transport support in AS 5. I suppose doing the same thing in the
standard org.jgroups.JChannelFactory class is possible, although I don't
advocate it at all; it seems hacky. Better IMO to adapt channel factory
users to call the correct method.
[1] Note that the hacky #2 approach is very likely to remain in AS 5
since JBM has the same usage as current JBC. So, getting this in JBC 2.1
is not a requirement for AS 5, just a "nice to have", something that if
done now can avoid future compatibility issues, etc.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
18 years, 3 months
