Btw, I'd rather go with Paul's suggestion to modify AS7 Infinispan subsystem. On Feb 8, 2012, at 4:25 PM, Galder Zamarreño wrote: > Scott, what do you suggest doing instead then? Without the commands, evictAll invalidation won't work. > > Are you suggesting that I revert back to using the cache as a notification bus so that regions are invalidated? > > On Feb 8, 2012, at 4:13 PM, Scott Marlow wrote: > >> http://lists.jboss.org/pipermail/infinispan-dev/2012-February/010125.html has more context. >> >> Since there are no easy/quick fixes that can be applied at this time, to remove the AS7 Infinispan dependency on the Hibernate-Infinispan module, I think we should avoid depending on the service loader way to supply the custom commands (in the Hibernate-Infinispan module), at least until this can be addressed elsewhere. >> >> I propose that the Hibernate-Infinispan second level cache should not use the Service Loader to pass custom commands into Infinispan. If we agree, I'll create a jira for this. >> >> Scott > > -- > 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 -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache

My very personal opinion is that if the user requires to "bring his own" Hibernate jars it is fair enough to require in turn that he should bring his own cache implementations as well.

It would be nice if we could test that one could then use different versions of Infinispan & JGroups, properly isolated from the ones WF provides.

In an ideal world such a different Infinispan version should have the option to reuse the "main" JGroups channel managed by the AS... but I realize that is still a long way to go. Sanne On 3 June 2013 18:37, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > Hi, > > I'm responding to this *old thread* to say that Paul's clustering magic > changes in AS7 resolved the dependency between the AS7 static Infinispan > module and the Hibernate-Infinispan module. *Thanks Paul* and others > for jumping through hoops for that. :) > > However, in WF8, I'm catching up on fixing bugs that prevented Hibernate > 4.x jars from being packaged with the application. With my local fixes, > I found that if the Hibernate jars are packaged with the application, > the WF8 Infinispan module will *not be able to* load the > Hibernate-Infinispan services (since the application deployment is not > visible to Infinispan service loading). > > Should we push on getting WF8 application deployments that contain the > Hibernate jars to work with the WF8 (system level) Infinispan module? > > Thanks, > Scott > > On 02/08/2012 10:27 AM, Galder Zamarreño wrote: >> Btw, I'd rather go with Paul's suggestion to modify AS7 Infinispan subsystem. >> >> On Feb 8, 2012, at 4:25 PM, Galder Zamarreño wrote: >> >>> Scott, what do you suggest doing instead then? Without the commands, evictAll invalidation won't work. >>> >>> Are you suggesting that I revert back to using the cache as a notification bus so that regions are invalidated? >>> >>> On Feb 8, 2012, at 4:13 PM, Scott Marlow wrote: >>> >>>> http://lists.jboss.org/pipermail/infinispan-dev/2012-February/010125.html has more context. >>>> >>>> Since there are no easy/quick fixes that can be applied at this time, to remove the AS7 Infinispan dependency on the Hibernate-Infinispan module, I think we should avoid depending on the service loader way to supply the custom commands (in the Hibernate-Infinispan module), at least until this can be addressed elsewhere. >>>> >>>> I propose that the Hibernate-Infinispan second level cache should not use the Service Loader to pass custom commands into Infinispan. If we agree, I'll create a jira for this. >>>> >>>> Scott >>> >>> -- >>> 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 >> >> -- >> 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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

> I think we would hit problems where the JPA EE container/subsystem side > interacts with the Infinispan (system) module (probably EJB3 code as well.) Right, I realize that, but there might be a solution coming we call "grafting" JGRP-1613

basically it should expose virtually independent channels so that multiple services needing an "owned" channel can use them without conflicts, but still sharing some protocols. So in the specific case of this discussion, people could reuse the ports, making it easier to configure and possibly faster to boot, but also reuse the cluster topology definition and failure detection, making it less awkward to use as in such a case you really don't want the topology from the AS to be out of sync with the topology used by some application cache. Sanne

On 4 June 2013 04:04, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > On 06/03/2013 07:20 PM, Sanne Grinovero wrote: >> >> My very personal opinion is that if the user requires to "bring his >> own" Hibernate jars it is fair enough to require in turn that he >> should bring his own cache implementations as well. > > > For a non-clustered 2lc application, they could include Infinispan jars with > the hibernate jars. > > For an application using a clustered 2lc, currently, the system Infinispan > jars are expected to be used (so that the Infinispan dependency on > Hibernate-Infinispan is met for proper initialization). Couldn't "we expect" that in such case people would be free to bring their own Infinispan jars and will be on their own to configure it? I don't see why they should not be able to configure a clustered cache, as long as they are careful to isolate ports, etc..

> > Most of the complaints that I hear, are about WFLY-1151 not allowing a > different version of Hibernate 4.x to be included in the deployment. After > the fix for that is in WF8, we might hear more about deployments bringing > their own Hibernate jars and not being able to use the (system level) > Infinispan 2lc. > > >> >> It would be nice if we could test that one could then use different >> versions of Infinispan & JGroups, properly isolated from the ones WF >> provides. > > > I think we would hit problems where the JPA EE container/subsystem side > interacts with the Infinispan (system) module (probably EJB3 code as well.) Right, I realize that, but there might be a solution coming we call "grafting" JGRP-1613 basically it should expose virtually independent channels so that multiple services needing an "owned" channel can use them without conflicts, but still sharing some protocols. So in the specific case of this discussion, people could reuse the ports, making it easier to configure and possibly faster to boot, but also reuse the cluster topology definition and failure detection, making it less awkward to use as in such a case you really don't want the topology from the AS to be out of sync with the topology used by some application cache. Sanne > > >> >> In an ideal world such a different Infinispan version should have the >> option to reuse the "main" JGroups channel managed by the AS... but I >> realize that is still a long way to go. >> >> Sanne >> >> On 3 June 2013 18:37, Scott Marlow <smarlow(a)redhat.com&gt; wrote: >>> >>> Hi, >>> >>> I'm responding to this *old thread* to say that Paul's clustering magic >>> changes in AS7 resolved the dependency between the AS7 static Infinispan >>> module and the Hibernate-Infinispan module. *Thanks Paul* and others >>> for jumping through hoops for that. :) >>> >>> However, in WF8, I'm catching up on fixing bugs that prevented Hibernate >>> 4.x jars from being packaged with the application. With my local fixes, >>> I found that if the Hibernate jars are packaged with the application, >>> the WF8 Infinispan module will *not be able to* load the >>> Hibernate-Infinispan services (since the application deployment is not >>> visible to Infinispan service loading). >>> >>> Should we push on getting WF8 application deployments that contain the >>> Hibernate jars to work with the WF8 (system level) Infinispan module? >>> >>> Thanks, >>> Scott >>> >>> On 02/08/2012 10:27 AM, Galder Zamarreño wrote: >>>> >>>> Btw, I'd rather go with Paul's suggestion to modify AS7 Infinispan >>>> subsystem. >>>> >>>> On Feb 8, 2012, at 4:25 PM, Galder Zamarreño wrote: >>>> >>>>> Scott, what do you suggest doing instead then? Without the commands, >>>>> evictAll invalidation won't work. >>>>> >>>>> Are you suggesting that I revert back to using the cache as a >>>>> notification bus so that regions are invalidated? >>>>> >>>>> On Feb 8, 2012, at 4:13 PM, Scott Marlow wrote: >>>>> >>>>>> >>>>>> http://lists.jboss.org/pipermail/infinispan-dev/2012-February/010125.html >>>>>> has more context. >>>>>> >>>>>> Since there are no easy/quick fixes that can be applied at this time, >>>>>> to remove the AS7 Infinispan dependency on the Hibernate-Infinispan module, >>>>>> I think we should avoid depending on the service loader way to supply the >>>>>> custom commands (in the Hibernate-Infinispan module), at least until this >>>>>> can be addressed elsewhere. >>>>>> >>>>>> I propose that the Hibernate-Infinispan second level cache should not >>>>>> use the Service Loader to pass custom commands into Infinispan. If we >>>>>> agree, I'll create a jira for this. >>>>>> >>>>>> Scott >>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>>> >>>> -- >>>> 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 >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >

On 02/08/2012 10:25 AM, Galder Zamarreño wrote: > Scott, what do you suggest doing instead then? Without the commands, evictAll invalidation won't work. > > Are you suggesting that I revert back to using the cache as a notification bus so that regions are invalidated? For the clustered case, is there a way to get the underlying JGroups channel and use that to make remote calls instead of using the cache as a notification bus?

On 9 Feb 2012, at 09:53, Dan Berindei wrote: The JGroups channel you get from JGroupsTransport.getChannel() can be used only by Infinispan. Why?  If we changed our CommandAwareRpcDispatcher to ignore messages that contain a certain header (say, INFINISPAN_IGNORE), then that channel can be reused as long as the header is used on all messages.

On 2/9/12 3:01 PM, Dan Berindei wrote: > On Thu, Feb 9, 2012 at 2:45 PM, Manik Surtani&lt;manik(a)jboss.org&gt;  wrote: >> >> On 9 Feb 2012, at 09:53, Dan Berindei wrote: >> >> The JGroups channel you get from JGroupsTransport.getChannel() can be >> used only by Infinispan. >> >> >> Why?  If we changed our CommandAwareRpcDispatcher to ignore messages that >> contain a certain header (say, INFINISPAN_IGNORE), then that channel can be >> reused as long as the header is used on all messages. >> > > But how would you install the handler on the receiving end? You'd > still need a mechanism to register the Hibernate handler with our > CommandAwareRpcDispatcher... > > I think it's simpler the other way around: create the channel outside > Infinispan, register your own receiver, and only pass to Infinispan > the messages that don't contain a certain header - kind of what the > muxing channel in AS7 does. Yes, this is already done in the MuxUpHandler written by Paul. If we can grab the JChannel, we can always insert ourselves into the Muxer, and thus invoke RPCs

On 2/9/12 3:24 PM, Sanne Grinovero wrote: > On 9 February 2012 14:09, Bela Ban&lt;bban(a)redhat.com&gt;  wrote: >> >> >> On 2/9/12 3:01 PM, Dan Berindei wrote: >>> On Thu, Feb 9, 2012 at 2:45 PM, Manik Surtani&lt;manik(a)jboss.org&gt;  Â wrote: >>>> >>>> On 9 Feb 2012, at 09:53, Dan Berindei wrote: >>>> >>>> The JGroups channel you get from JGroupsTransport.getChannel() can be >>>> used only by Infinispan. >>>> >>>> >>>> Why? Â If we changed our CommandAwareRpcDispatcher to ignore messages that >>>> contain a certain header (say, INFINISPAN_IGNORE), then that channel can be >>>> reused as long as the header is used on all messages. >>>> >>> >>> But how would you install the handler on the receiving end? You'd >>> still need a mechanism to register the Hibernate handler with our >>> CommandAwareRpcDispatcher... >>> >>> I think it's simpler the other way around: create the channel outside >>> Infinispan, register your own receiver, and only pass to Infinispan >>> the messages that don't contain a certain header - kind of what the >>> muxing channel in AS7 does. >> >> Yes, this is already done in the MuxUpHandler written by Paul. If we can >> grab the JChannel, we can always insert ourselves into the Muxer, and >> thus invoke RPCs > > Is there an example of how I could use that (for a different problem) ? > Or pointers to the source code or tests would be appreciated as well. There are 2 tests in JGroups: MuxRpcDispatcherTest and MuxMessageDispatcherTest, both written by PaulF.

On 9 February 2012 15:37, Bela Ban <bban(a)redhat.com&gt; wrote: > > > On 2/9/12 3:24 PM, Sanne Grinovero wrote: >> On 9 February 2012 14:09, Bela Ban&lt;bban(a)redhat.com&gt; wrote: >>> >>> >>> On 2/9/12 3:01 PM, Dan Berindei wrote: >>>> On Thu, Feb 9, 2012 at 2:45 PM, Manik Surtani&lt;manik(a)jboss.org&gt; Â wrote: >>>>> >>>>> On 9 Feb 2012, at 09:53, Dan Berindei wrote: >>>>> >>>>> The JGroups channel you get from JGroupsTransport.getChannel() can be >>>>> used only by Infinispan. >>>>> >>>>> >>>>> Why? Â If we changed our CommandAwareRpcDispatcher to ignore messages that >>>>> contain a certain header (say, INFINISPAN_IGNORE), then that channel can be >>>>> reused as long as the header is used on all messages. >>>>> >>>> >>>> But how would you install the handler on the receiving end? You'd >>>> still need a mechanism to register the Hibernate handler with our >>>> CommandAwareRpcDispatcher... >>>> >>>> I think it's simpler the other way around: create the channel outside >>>> Infinispan, register your own receiver, and only pass to Infinispan >>>> the messages that don't contain a certain header - kind of what the >>>> muxing channel in AS7 does. >>> >>> Yes, this is already done in the MuxUpHandler written by Paul. If we can >>> grab the JChannel, we can always insert ourselves into the Muxer, and >>> thus invoke RPCs >> >> Is there an example of how I could use that (for a different problem) ? >> Or pointers to the source code or tests would be appreciated as well. > > > There are 2 tests in JGroups: MuxRpcDispatcherTest and > MuxMessageDispatcherTest, both written by PaulF. Thanks! But is this the same implementation used by AS7 ? I had understood that there where two, and I would like to know specifically how to use the (already muxed) channel provided by the application server if I look it up from JNDI, so to have a way for applications to reuse the already started JGroups instance.

Sanne _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Scott, what do you suggest doing instead then? Without the commands, evictAll invalidation won't work. Are you suggesting that I revert back to using the cache as a notification bus so that regions are invalidated? On Feb 8, 2012, at 4:13 PM, Scott Marlow wrote: > http://lists.jboss.org/pipermail/infinispan-dev/2012-February/010125.html has more context. > > Since there are no easy/quick fixes that can be applied at this time, to remove the AS7 Infinispan dependency on the Hibernate-Infinispan module, I think we should avoid depending on the service loader way to supply the custom commands (in the Hibernate-Infinispan module), at least until this can be addressed elsewhere. > > I propose that the Hibernate-Infinispan second level cache should not use the Service Loader to pass custom commands into Infinispan. If we agree, I'll create a jira for this. > > Scott -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache