JGroups Shared Transport support in JBC

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.stansberryredhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Brian Stansberry wrote:
> 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?

I changed this in the 2.6 branch, however, as 2.6.2 was
released 
yesterday I cannot add it to 2.6.2...


-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Bela Ban wrote:
> 
> 
> Brian Stansberry wrote:
>> 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?
> 
> I changed this in the 2.6 branch, however, as 2.6.2 was
released 
> yesterday I cannot add it to 2.6.2...
> 

Oh well. I just noticed it not being in the interface when I
started 
drafting this. :(


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberryredhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Should have told me yesterday... 

Brian Stansberry wrote:
> Bela Ban wrote:
>>
>>
>> Brian Stansberry wrote:
>>> 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?
>>
>> I changed this in the 2.6 branch, however, as 2.6.2
was released 
>> yesterday I cannot add it to 2.6.2...
>>
>
> Oh well. I just noticed it not being in the interface
when I started 
> drafting this. :(
>
>

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat

_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Bela Ban wrote:
> 
> 
> Brian Stansberry wrote:
>> 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?
> 
> I changed this in the 2.6 branch, however, as 2.6.2 was
released 
> yesterday I cannot add it to 2.6.2...
> 

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 
(ht
tp://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. 
If we can get a JGroups 2.6.3 and JBC 2.1.0.GA able to call

ChannelFactory.createChannel(), then I can just let JBM get
a MuxChannel.

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberryredhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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 
>>> (ht
tp://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
> manikjboss.org
> msurtaniredhat.com
>
>
>

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat

_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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 
> (ht
tp://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
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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 
>>>>>> (ht
tp://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
>>>> manikjboss.org
>>>> msurtaniredhat.com
>>>>
>>>>
>>>>
>>>
>>> -- 
>>> Bela Ban
>>> Lead JGroups / Clustering Team
>>> JBoss - a division of Red Hat
>>>
>>
>> -- 
>> Manik Surtani
>> Lead, JBoss Cache
>> manikjboss.org
>> msurtaniredhat.com
>>
>>
>>
> 

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberryredhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Sure, no problem.

When are you expecting 1.4.1.beta2 out?

Tim Fox wrote:
> Yeah this is probably a trivial change on our side, but
we just haven't 
> got round to looking at it yet. :(
> 
> If it's high priority I'll take a look soon, tomorrow
ok?
> 
> Cheers
> 
> Brian Stansberry wrote:
>> 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 
>>>>>>>> (ht
tp://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
>>>>>> manikjboss.org
>>>>>> msurtaniredhat.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> -- 
>>>>> Bela Ban
>>>>> Lead JGroups / Clustering Team
>>>>> JBoss - a division of Red Hat
>>>>>
>>>>
>>>> -- 
>>>> Manik Surtani
>>>> Lead, JBoss Cache
>>>> manikjboss.org
>>>> msurtaniredhat.com
>>>>
>>>>
>>>>
>>>
>>
> 

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberryredhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev