[infinispan-dev] Ability to retrieve a JChannel via multiplexer stack name, where is it gone?
Galder Zamarreno
galder at redhat.com
Fri Dec 4 07:19:56 EST 2009
On 12/03/2009 02:47 PM, Manik Surtani wrote:
>
> On 3 Dec 2009, at 10:55, Galder Zamarreno wrote:
>
>>
>>
>> On 12/02/2009 01:58 PM, Manik Surtani wrote:
>>>
>>> On 1 Dec 2009, at 12:52, Galder Zamarreno wrote:
>>>
>>>> Hi,
>>>>
>>>> Re: "* I'm adding the Infinispan 2nd level cache provider to existing
>>>> servers that already use JGroups. Should I set Infinispan to use the
>>>> same JGroups cluster, or should I use two separate cluster names?" FAQ
>>>>
>>>> Where is the ability to get a JChannel via multiplexerStack gone? I
>>>> don't see any reference to such XML configuration property. Is this
>>>> supposed to be hiding behind an
>>>> org.infinispan.remoting.transport.jgroups.JGroupsChannelLookup
>>>> implementation? I can only see a dummy implementation for it currently.
>>>
>>> You mean the ability to inject a running Channel into Infinispan so Infinispan doesn't create one? See
>>>
>>> https://jira.jboss.org/jira/browse/ISPN-185
>>
>> Yeah, the interface is there but there's no implementation for it yet
>> though, is it?
>
> There is no such thing as a standard impl. :) Any impl you provide will be able to grab a channel from wherever you have it (e.g., in a Microcontainer, etc) and pass it in to Infinispan.
>
>>
>>>
>>> The JGroups Multiplexer is deprecated, BTW. You should configure JGroups with a shared transport for such cases.
>>
>> AFAIK, the concept of multiplexer is deprecated but AFAIR, when you want
>> to run a JBoss Cache instance with 'udp' shared transport, you still had
>> to use the ChannelFactory.createMultiplexerChannel(*) methods.
>>
>> What I'm trying to say here is that currently, I don't see any
>> implementation of ISPN-185 that would take the name of a shared
>> transport stack, i.e. 'udp', and use that to ask JGroups to provide a
>> channel for that.
>
> An impl of JGroupsChannelLookup that you would provide is supposed to either look up or create a channel and pass it to Infinispan. Think TransactionManagerLookup, exactly the same.
>
>> I mean, users could create such implementation if they want, but we
>> should provide one so that they don't have to do so?
>
> What would the default we provide do? :)
Hmmm, the default (called StandaloneJGroupsChannelLookup) should
probably do what JBC did which is:
- Take the shared transport name or multiplexer name via a property
- Take the mux channel factory (prob hardcoded to
org.jgroups.JChannelFactory)
- Return a JChannel with it:
private JChannel getMultiplexerChannel() throws CacheException
{
String stackName = configuration.getMultiplexerStack();
RuntimeConfig rtc = configuration.getRuntimeConfig();
ChannelFactory channelFactory = rtc.getMuxChannelFactory();
JChannel muxchannel = null;
if (channelFactory != null)
{
try
{
muxchannel = (JChannel)
channelFactory.createMultiplexerChannel(stackName,
configuration.getClusterName());
}
catch (Exception e)
{
throw new CacheException("Failed to create multiplexed
channel using stack " + stackName, e);
}
}
if (trace) {
if (muxchannel == null) {
log.trace("Null mux channel!");
} else {
log.trace("Using multiplex channel: " +
muxchannel.printProtocolSpec(true));
}
}
return muxchannel;
}
XML:
<global>
<transport transportClass =
"org.infinispan.remoting.transport.jgroups.JGroupsTransport"
clusterName="infinispan-hibernate-cluster"
distributedSyncTimeout="50000">
<properties>
<property name="channelLookup"
value="StandaloneJGroupsChannelLookup"/>
<property name="transportName" value="udp"/>
</properties>
<!-- See the JGroupsTransport javadocs for more flags -->
</transport>
</global>
Now, IIRC, this is the same stuff as you do with shared transport. To
avoid API changes, I remember Bela saying that we'd use multiplexer*
method properties but they mean shared transport.
What do we get with this? This would, if I understand this correctly, to
start two clusters in the same VM, with different cluster names, and get
both to use the same factory and same transport.
We'd then have a diff implementation when this Infinispan instances are
actually running under AS. There're would be like an
ASJGroupsTrasnportLookup.
>
>> And where are we
>> gonna configure the name of the shared transport to join to?
>
> This bit escapes me - AFAIR this is configured in the JGroups stack, used to create a channel, which is passed back via the lookup?
Sure, but a way to externalize to XML so that they can change it as you
did with JBC?
>
> Cheers
> Manik
>
>>
>>
>>>
>>> Cheers
>>> --
>>> Manik Surtani
>>> manik at jboss.org
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> http://www.infinispan.org
>>> http://www.jbosscache.org
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
More information about the infinispan-dev
mailing list