[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