[infinispan-dev] Ability to retrieve a JChannel via multiplexer stack name, where is it gone?

[Brian Stansberry]

On 12/04/2009 06:46 AM, Manik Surtani wrote:
>
> On 4 Dec 2009, at 12:19, Galder Zamarreno wrote:
>>>> 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:
>>
>
> JGroups' ChannelFactory is deprecated and no longer recommended for use.
>
> 	http://javagroups.cvs.sourceforge.net/viewvc/javagroups/JGroups/src/org/jgroups/ChannelFactory.java?revision=1.13&view=markup
>

I think the JGroups community should come up with and publish something 
like ChannelFactory if JGroups itself drops it. It's quite useful -- a 
class that parses a stacks.xml and presents an API for instantiating 
channels. Reinventing that particular wheel in every project that uses 
JGroups seems silly. I'd be perfectly happy to publish the AS's 
ChannelFactory impl as a separate module with no dependencies other than 
JGroups itself.

>
>
>>     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
>> _______________________________________________
>> 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


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