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

The JGroups Multiplexer is deprecated, BTW. You should configure JGroups with a shared transport for such cases.

Cheers -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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? :)

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

Cheers Manik > > >> >> Cheers >> -- >> Manik Surtani >> manik(a)jboss.org >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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/j...

> 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(a)jboss.org >>>> Lead, Infinispan >>>> Lead, JBoss Cache >>>> http://www.infinispan.org >>>> http://www.jbosscache.org >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Manik Surtani >> manik(a)jboss.org >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Brian Stansberry wrote: > 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/j... >> >> > > 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. If you want to maintain it, we can leave it in JGroups...