Re: [infinispan-dev] Obtaining cache via CDI on WildFly

[Paul Ferraro]

Gunnar,

While WF doesn't include infinispan-cdi integration, you can inject
Infinispan caches defined within the Infinispan subsystem as standard
EE resources via the their JNDI bindings.  This approach has the
advantage of container-managed lifecycle of the cache, even when
referenced by multiple deployments.

e.g.
@Resource(lookup = "java:jboss/infinispan/cache/foo/bar")
private Cache cache; // References the "bar" cache of the "foo"
cache container

or

@Resource(lookup = "java:jboss/infinispan/cache/foo/default")
private Cache cache; // References the default cache of the
"foo" cache container

Unfortunately, a long standing weld integration bug prevents @Resource
lookups from working correctly when the containing class is
instrumented by CDI.  To workaround this, move the JNDI lookup to a
 or  in your deployment descriptor
and reference your cache resource via its reference name.

e.g.

my-cache
org.infinispan.Cache
java:jboss/infinispan/cache/foo/bar


@Resource(name = "my-cache")
private Cache cache;

Paul
On Wed, Dec 5, 2018 at 3:47 AM Gunnar Morling  wrote:
>
> Hey,
>
> I was trying to configure and inject an Infinispan cache through CDI,
> running on WildFly 14, using the Infinispan modules provided by the
> server.
>
> While I'm not sure whether that's something supported or recommended,
> I found this preferable over adding Infinispan another time as part of
> the deployment. I couldn't find any recent info on doing this (would
> love any pointers, though), so here's my findings, in case it's
> interesting for others:
>
> * A jboss-deployment-structure.xml file is needed for adding the
> dependencies to the modules org.infinispan and org.infinispan.commons
> * Unlike the core module, org.infinispan:infinispan-cdi-embedded isn't
> part of WF, so it must be added to the deployment
> * The transitive dependency from infinispan-cdi-embedded to
> org.infinispan:infinispan-commons must be excluded, otherwise linking
> errors will occur
>
> Perhaps a small example of this could be added to the Infinispan docs?
>
> Btw. I also couldn't find an example for configuring a cache through
> jboss-cli.sh, perhaps that's something to consider, too?
>
> Cheers,
>
> --Gunnar
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] ISPN-8798 ByteString places too strict a constraint on cache name length

[Paul Ferraro]

Excellent.  Thanks a million.

On Tue, Feb 13, 2018 at 8:33 AM, Tristan Tarrant <ttarr...@redhat.com> wrote:
> We can cut 9.1.6.Final today.
>
> --
> Tristan Tarrant
> Infinispan Lead & Data Grid Architect
> Red Hat
>
> On 13 Feb 2018 14:21, "Paul Ferraro" <paul.ferr...@redhat.com> wrote:
>>
>> Can one of the devs please review this patch?
>> https://github.com/infinispan/infinispan/pull/5750
>>
>> The limit of cache names sizes to 127 bytes is too limiting for
>> hibernate/JPA 2nd level cache deployments, which generate cache names
>> using fully qualified class names of entity classes, which are user
>> generated thus can easily exceed 128 bytes (but are far less likely to
>> exceed 255).  This is exacerbated by the JPA integration, which
>> additionally appends the deployment name.  We have a long term
>> solution for this, but in the meantime, the above patch is sufficient
>> to pass the TCK.
>>
>> We'll also need a 9.1.6.Final release ASAP, lest we revert back to
>> Infinispan 8.2.x for WF12, the feature freeze for which is tomorrow
>> (they are considering this upgrade a feature, given the scope of its
>> impact).
>>
>> Thanks,
>>
>> Paul
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

[infinispan-dev] ISPN-8798 ByteString places too strict a constraint on cache name length

[Paul Ferraro]

Can one of the devs please review this patch?
https://github.com/infinispan/infinispan/pull/5750

The limit of cache names sizes to 127 bytes is too limiting for
hibernate/JPA 2nd level cache deployments, which generate cache names
using fully qualified class names of entity classes, which are user
generated thus can easily exceed 128 bytes (but are far less likely to
exceed 255).  This is exacerbated by the JPA integration, which
additionally appends the deployment name.  We have a long term
solution for this, but in the meantime, the above patch is sufficient
to pass the TCK.

We'll also need a 9.1.6.Final release ASAP, lest we revert back to
Infinispan 8.2.x for WF12, the feature freeze for which is tomorrow
(they are considering this upgrade a feature, given the scope of its
impact).

Thanks,

Paul
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] IRC chat: HB + I9

[Paul Ferraro]

ED in
>> default configuration - isolation level does not apply at all to
>> non-transactional caches, so please remove that as it would be just a noise.
>>
>> Radim
>>
>> On 05/23/2017 03:07 PM, Galder Zamarreño wrote:
>>> Hi all,
>>>
>>> I've just finished integrating Infinispan with a HB 6.x branch Steve had, 
>>> all tests pass now [1].
>>>
>>> Yeah, we didn't commit on the final location for these changes.
>>>
>>> As far as I know, Hibernate master is not 6.x, but rather 5.2.x. There's no 
>>> 5.2.x branch in Hibernate main repo. 6.x is just a branch that Steve has.
>>>
>>> These are the options availble to us:
>>>
>>> 1. Integrate 9.x provider as part of 'hibernate-infinispan' in Hibernate 
>>> 6.x branch.
>>>
>>> 2. Integrate 9.x provider as part of a second Infinispan module in 
>>> Hibernate 5.x branch.
>>>
>>> 3. Integrate 9.x provider as part of 'hibernate-infinispan' in Hibernate 
>>> 5.x branch. This is problematic for since the provider is not backwards 
>>> compatible.
>>>
>>> 4. Integrate 9.x provider in infinispan and deliver it as part of 
>>> Infinispan rather than Hibernate.
>>>
>>> I'm not sure which one I prefer the most TBH... 1. is the ideal solution 
>>> but doesn't seem there will be a Hibernate 6.x release for a while. 
>>> 2./3./4. all have their downsides... :\
>>>
>>> Thoughts?
>>>
>>> [1] https://github.com/galderz/hibernate-orm/commits/t_i9x_v2
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 16 May 2017, at 17:06, Paul Ferraro <paul.ferr...@redhat.com> wrote:
>>>>
>>>> Thanks Galder.  I read through the infinispan-dev thread on the
>>>> subject, but I'm not sure what was concluded regarding the eventual
>>>> home for this code.
>>>> Once the testsuite passes, is the plan to commit to hibernate master?
>>>> If so, I will likely fork  
>>>>these changes into a WF module (and adapt it
>>>> for Hibernate 5.1.x) so that WF12 can move to JGroups4+Infinispan9
>>>> until Hibernate6 is integrated.
>>>>
>>>> Radim - one thing you mentioned on that infinispan-dev thread puzzled
>>>> me: you said that invalidation mode offers no benefits over
>>>> replication.  How is that possible?  Can you elaborate?
>>>>
>>>> Paul
>>>>
>>>> On Tue, May 16, 2017 at 9:03 AM, Galder Zamarreño <gal...@redhat.com> 
>>>> wrote:
>>>>> I'm on the move, not sure if Paul/Radim saw my replies:
>>>>>
>>>>>  galderz, rvansa: Hey guys - is there a plan for Hibernate &
>>>>> ISPN 9?
>>>>>  pferraro: Galder has been working on that
>>>>>  pferraro: though I haven't seen any results but a list of
>>>>> stuff that needs to be changed
>>>>>  galderz: which Hibernate branch are you targeting?
>>>>>  pferraro: 5.2, but there are minute differences between 5.x
>>>>> in terms of the parts that need love to get Infinispan 9 support
>>>>> *** Mode change: +v vblagoje on #infinispan by ChanServ
>>>>> (ChanServ@services.)
>>>>>  rvansa: are you suggesting that 5.0 or 5.1 branches will be
>>>>> adapted to additionally support infinispan 9?  how is that
>>>>> possible?
>>>>>> pferraro: i'm working on it as we speak...
>>>>>> pferraro: down to 16 failuresd
>>>>>> pferraro: i started a couple of months ago, but had talks/demos to
>>>>> prepare
>>>>>> pferraro: i've got back to working on it this week
>>>>> ...
>>>>>> pferraro: rvansa
>>>>>> rvansa: minute differences my ass ;p
>>>>>> pferraro: did you see my replies?
>>>>>> i got disconnected while replying...
>>>>>  hmm - no - I didn't
>>>>>  galderz: ^
>>>>>> pferraro: so, working on the HB + I9 integration as we speak
>>>>>> pferraro: i started a couple of months back but had talks/demos to
>>>>> prepare and had to put that aside
>>>>>> pferraro: i'm down to 16 failures
>>>>>> pferraro: serious refactoring required of the integration to get it
>>>>> to compile and the tests to pass
>>>>>> pferraro: need to switch to async interceptor stack in 2lc
>>>>> integration and get all the subtle changes right
>>>>>> pferraro: it's a painstaking job basically
>>>>>> pferraro: i'm working on
>>>>> https://github.com/galderz/hibernate-orm/tree/t_i9x_v2
>>>>>> pferraro: i can't remember where i branched off, but it's a branch
>>>>> that steve had since master was focused on 5.x
>>>>>> pferraro: i've no idea when/where we'll integrate this, but one
>>>>> thing is for sure: it's nowhere near backwards compatible
>>>>>> actually, fixed one this morning, so down to 15 failures
>>>>>> pferraro: any suggestions/wishes?
>>>>>> is anyone out there? ;)
>>>>> Cheers,
>>>>> --
>>>>> Galder Zamarreño
>>>>> Infinispan, Red Hat
>>>>>
>>
>>
>> --
>> Radim Vansa <rva...@redhat.com>
>> JBoss Performance Team
>>
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] IRC chat: HB + I9

[Paul Ferraro]

Thanks Galder.  I read through the infinispan-dev thread on the
subject, but I'm not sure what was concluded regarding the eventual
home for this code.
Once the testsuite passes, is the plan to commit to hibernate master?
If so, I will likely fork these changes into a WF module (and adapt it
for Hibernate 5.1.x) so that WF12 can move to JGroups4+Infinispan9
until Hibernate6 is integrated.

Radim - one thing you mentioned on that infinispan-dev thread puzzled
me: you said that invalidation mode offers no benefits over
replication.  How is that possible?  Can you elaborate?

Paul

On Tue, May 16, 2017 at 9:03 AM, Galder Zamarreño  wrote:
> I'm on the move, not sure if Paul/Radim saw my replies:
>
>  galderz, rvansa: Hey guys - is there a plan for Hibernate &
> ISPN 9?
>  pferraro: Galder has been working on that
>  pferraro: though I haven't seen any results but a list of
> stuff that needs to be changed
>  galderz: which Hibernate branch are you targeting?
>  pferraro: 5.2, but there are minute differences between 5.x
> in terms of the parts that need love to get Infinispan 9 support
> *** Mode change: +v vblagoje on #infinispan by ChanServ
> (ChanServ@services.)
>  rvansa: are you suggesting that 5.0 or 5.1 branches will be
> adapted to additionally support infinispan 9?  how is that
> possible?
>> pferraro: i'm working on it as we speak...
>> pferraro: down to 16 failuresd
>> pferraro: i started a couple of months ago, but had talks/demos to
> prepare
>> pferraro: i've got back to working on it this week
> ...
>> pferraro: rvansa
>> rvansa: minute differences my ass ;p
>> pferraro: did you see my replies?
>> i got disconnected while replying...
>  hmm - no - I didn't
>  galderz: ^
>> pferraro: so, working on the HB + I9 integration as we speak
>> pferraro: i started a couple of months back but had talks/demos to
> prepare and had to put that aside
>> pferraro: i'm down to 16 failures
>> pferraro: serious refactoring required of the integration to get it
> to compile and the tests to pass
>> pferraro: need to switch to async interceptor stack in 2lc
> integration and get all the subtle changes right
>> pferraro: it's a painstaking job basically
>> pferraro: i'm working on
> https://github.com/galderz/hibernate-orm/tree/t_i9x_v2
>> pferraro: i can't remember where i branched off, but it's a branch
> that steve had since master was focused on 5.x
>> pferraro: i've no idea when/where we'll integrate this, but one
> thing is for sure: it's nowhere near backwards compatible
>> actually, fixed one this morning, so down to 15 failures
>> pferraro: any suggestions/wishes?
>> is anyone out there? ;)
>
> Cheers,
> --
> Galder Zamarreño
> Infinispan, Red Hat
>

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Auto-detection of appropriate key2StringMapperClass

[Paul Ferraro]

Funny that you mention this, because I need to implement this for
WildFly.next to support Infinispan 9, where the binary key store is no
longer an option.  We need to be able to map complex keys for storing
web sessions, Hibernate keys, and @Stateful EJBs to strings.
An auto-discovered mapper is simple enough to integrate into WF since
we allow a given cache-container to be configured with a specific
module, from which marshalling services are auto-discovered.

Paul

On Wed, Mar 8, 2017 at 11:34 AM, Sanne Grinovero  wrote:
> It seems I keep forgetting that the "key2StringMapperClass" needs to
> be explicitly set when using the String based JDBC CacheStore, which I
> think is a quite popular store.
>
> http://infinispan.org/docs/dev/user_guide/user_guide.html#storing_the_index_in_a_database
>
> I think we could remove the need to configure this with an appropriate
> service discovery?
>
> We could keep the property so to be able to override the discovery process.
>
> Would anyone volunteer to implement this?
>
> Thanks,
> Sanne
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] XSite route status listener in server - ISPN-7230/ISPN-7231

[Paul Ferraro]

Hi Galder,

Sorry for the delay.  For server-mode, we'd need to set the
RouteStatusListener in the jgroups subsystem before the RELAY2
protocol is initialized.
e.g.
public class DefaultRouteStatusListener implements
RouteStatusListener, Supplier {
private final Set view = new ConcurrentSkipListSet<>();
@Override
public void sitesUp(String... sites) {
this.view.addAll(Arrays.asList(sites));
log.receivedXSiteClusterView(view);
}
@Override
public void sitesDown(String... sites) {
this.view.removeAll(Arrays.asList(sites));
log.receivedXSiteClusterView(view);
}
@Override
public Set get() {
return Collections.unmodifiableSet(this.view);
}
}

We would set the RouteStatusListener following this line from JChannelFactory:
https://github.com/infinispan/infinispan/blob/master/server/integration/jgroups/src/main/java/org/infinispan/server/jgroups/JChannelFactory.java#L136
e.g.
RELAY2 relay = new RELAY2().site(localSite);
relay.setRouteStatusListener(new DefaultRouteStatusListener());

JGroupsTransport can then obtain the site view via:
@Override
public Set getSitesView() {
RELAY2 relay = channel.getProtocolStack().findProtocol(RELAY2.class);
RouteStatusListener listener = (relay != null) ?
relay.getRouteStatusListener() : null;
return (listener instanceof Supplier) ? ((Supplier)
listener).get() : null;
}

On Thu, Jan 12, 2017 at 6:10 AM, Galder Zamarreño  wrote:
> Hi Paul,
>
> Sorry to bother you again :)
>
> Re: https://issues.jboss.org/browse/ISPN-7230 & 
> https://issues.jboss.org/browse/ISPN-7231
>
> The aim of these JIRAs is to have a x-site view exposed as an INFO message as 
> well as JMX and DMR operation.
>
> To do that, following Bela's advice, I've extracted RELAY2 protocol of the 
> stack and on Infinispan's JGroupsTransport start() method, call 
> setRouteStatusListener() with a relay RouteStatusListener implementation that 
> allows the x-site view to be tracked [1].
>
> This works fine in library mode, but in server, on startup 
> setRouteStatusListener() sometimes gets called after the Relayer's 
> viewAccepted() method has been already called (which is the one that calls 
> into RouteStatusListener). These means that the inital x-site view might not 
> be registered.
>
> So, what would be the correct place to add the setRouteStatusListener() call 
> so that all views are captured? Or given how the server works, do I need to 
> avoid using setRouteStatusListener() and use my own, Infinispan level, 
> listener for tracking somehow?
>
> Cheers,
>
> [1] 
> https://github.com/galderz/infinispan/blob/t_7230/core/src/main/java/org/infinispan/remoting/transport/jgroups/JGroupsTransport.java#L926
> --
> Galder Zamarreño
> Infinispan, Red Hat
>

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Property substitution for attributes that are part of paths - ISPN-7326

[Paul Ferraro]

On Tue, Jan 10, 2017 at 5:09 AM, Galder Zamarreño <gal...@redhat.com> wrote:
> Hey Paul,
>
> Thanks for the quick answer.
>
> The motivation for ISPN-7326 is to reduce domain configuration needed to test 
> xsite replication in the Javascript client. Without ISPN-7326 I'm having to 
> duplicate profiles for each site where the changing values are minimal. It 
> would be helpful to control the values I mentioned via system property to 
> reduce the number of profiles required in the domain config.
>
> The reason I'm interested in reducing the number of changes I make the 
> default domain config (e.g. by reducing number of profiles) is to make it 
> easier in the future to migrate to newer domain configurations.
>
> To be more precise, domain.xml in [1] contains 3 clustered profiles: 
> 'clustered', 'earth' and 'moon'. This makes the configuration for testing 
> clustered and xsite capabilities quite verbose. Ideally, I'd like to have 1 
> clustered profile, 'clustered', and using system properties select which 
> transport to use and provide optional site names...etc where needed.
>
> So indeed, the motivation for this is not a real environment.

I see.  So long as we go with approach #2, I think this is worthwhile.

> Your sugggestion for 2. doesn't sound too bad. Note that a similar approach 
> would be required for remote-site's name.

Ah, you mean for the JGroups remote-site config in the RELAY2
protocol.  Yeah, that shouldn't be too bad either.
e.g.





Here the site attribute of the relay resource must reference the
remote-site resource by it's name (because it is a model reference).
The relay resource's service handler currently stores the remote-sites
in a list.  We'll want to change this to map them by name.  Obtaining
the actual site-name (i.e. the value returned by
RelayConfiguration.getSiteName()) becomes a simple map lookup, now
that the site name is decoupled from the resource name.  We can still
make site-name optional, and default it to the resource name if
undefined.

I've opened https://issues.jboss.org/browse/WFLY-7871

Paul

> Thoughts?
>
> [1] 
> https://github.com/galderz/js-client/blob/16c985e0957c10f332c0dc9b561997c3f88c1c24/spec/configs/domain.xml
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 9 Jan 2017, at 17:47, Paul Ferraro <paul.ferr...@redhat.com> wrote:
>>
>> Hi Galder,
>>
>> The short answer: Attributes that are components of a resource path
>> address may not contain expressions.
>>
>> What is the motivation behind ISPN-7326?
>>
>> When the x-site domain model for Infinispan was originally designed,
>> the assumption was that a domain controller would never attempt to
>> manage a host residing in a remote data center.  Typically a domain
>> controller doesn't manage hosts outside of its own network.  Even an
>> architecture that uses multiple logical sites within the same physical
>> data center would still isolate each site to a separate network.
>>
>> Question aside, there are at least 2 ways we can do this:
>>
>> 1. Refactor the model.  Remove the backup resource entirely.  This
>> means that individual site configurations will no longer be
>> addressable.  Instead, the parent resource would maintain a list of
>> backup objects, where "site" becomes a normal attribute that allows
>> expressions.
>>
>> Dealing with complex object types in the model isn't exactly a
>> pleasurable experience, so I would first make sure that the
>> requirement is legitimate/realistic and thus warrants the change.  Of
>> course, the biggest headache will be the model transformations
>> required to support mixed domains (mixed domains are a reality of
>> upgrading), as well as translation of domain operations that reference
>> the legacy resources.
>>
>> 2. Decouple the logical backup name from the actual site name:
>>
>> 
>>
>> 
>>
>> Here, each host has an addressable "remote" backup resource, where the
>> site name is an expression and resolves to a host-specific value.
>> Additionally, we can make this site attribute optional, and have it
>> default to the backup name if undefined.
>>
>> In conclusion, if this is confirmed to be a genuine feature request, I
>> would strongly encourage you to go with option #2.
>>
>> Paul
>>
>> On Mon, Jan 9, 2017 at 8:49 AM, Galder Zamarreño <gal...@redhat.com> wrote:
>>> Hey Paul,
>>>
>>> Re: https://issues.jboss.org/browse/ISPN-7326
>>>
>>> I have some doubts how to achieve what I'm trying to do in ^
>>>
>>> More specifically, backup's 'site' attribut

Re: [infinispan-dev] Default cache

[Paul Ferraro]

On Wed, Nov 30, 2016 at 12:41 PM, Tristan Tarrant <ttarr...@redhat.com> wrote:
> On 30/11/16 17:44, Paul Ferraro wrote:
>> On Wed, Nov 30, 2016 at 9:13 AM, Tristan Tarrant <ttarr...@redhat.com> wrote:
>>> Some additional notes:
>>>
>>> - currently the XSD specifies the default-cache attribute on the
>>> cache-container element as required, but the parser doesn't enforce it.
>>> - A default ConfigurationBuilder is created for the default cache if one
>>> has not been specified
>>>
>>> My questions:
>>>
>>> 1. do we want the default cache to be optional or actually require it in
>>> the declarative configuration ?
>>
>> In WildFly, default-cache has been optional since WF8.  The
>> cache-container used for hibernate 2LC, for example, does not have any
>> concept of a default-cache.  So, for us anyway, it makes sense for
>> default-cache to be optional.  However, we have the luxury of falling
>> back to Infinispan's default getCache() logic in the event that no
>> default-cache was specified.
>>
>>> ** A: no enforcement. In this case requesting the default cache should
>>> print a warning about falling back to a "default" empty configuration.
>>>
>>> ** B: we don't require the user to specify a default cache in the
>>> configuration, but invoking getCache() will throw an exception.
>>>
>>> ** C: enforce it, although this will break all those XML files who
>>> haven't specified it.
>>>
>>> My preference is to use the namespace version and go for the A approach
>>> for < 9.0 and the B approach otherwise.
>>
>> I think that makes sense.
>>
>>> 2. currently, requesting a named cache for which a configuration hasn't
>>> been defined implicitly creates the cache by using the default
>>> configuration as a template.
>>>
>>> ** A: continue as is
>>>
>>> ** B: continue to implicitly create a cache, but use an empty
>>> configuration instead of using the default configuration, as this has
>>> been the source of confusion among users. Also print a warning.
>>>
>>> ** C: do not create caches unless a configuration has been explicitly
>>> provided.
>>>
>>> My preference is to use the namespace version and go for the A approach
>>> for < 9.0 and the C approach otherwise.
>>
>> Agreed.
>>
>>> Unfortunately the namespace version trick doesn't work for programmatic
>>> configurations. Probably we should add a boolean flag on the
>>> GlobalConfigurationManager (e.g. implicitCacheCreation) which defaults
>>> to false (because that's the "new order") but allows switching to the
>>> old behaviour if needed.
>>>
>>> In any case I'd like to also introduce a JCache-like createCache() API
>>
>> I think it would be best/cleanest if caches created via this API are
>> anonymous (i.e. not managed by the cache manager or made accessible
>> via getCache(String)).  That way there is no ambiguity about who is
>> meant to manage the lifecycle (user vs container).
>
> Hmm, this differs from the behaviour of JCache's getCache(String) though.

Yes - and this was one of my biggest complaints about this API.  There
ought to be a distinction between "managed" caches vs. "ad hoc"
caches.  This (along with the class loading mess) is one of the
reasons why this spec isn't ready for the EE world.

>>> Tristan
>>>
>>> On 10/11/16 13:20, Paul Ferraro wrote:
>>>> +1000
>>>>
>>>> This is precisely how we've setup cache manager semantics in WildFly
>>>> (since AS7):
>>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/spi/src/main/java/org/wildfly/clustering/infinispan/spi/CacheContainer.java
>>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/DefaultCacheContainer.java
>>>>
>>>> I'd love to be able to drop this.
>>>>
>>>> Paul
>>>>
>>>> On Thu, Nov 10, 2016 at 3:38 AM, Tristan Tarrant <ttarr...@redhat.com> 
>>>> wrote:
>>>>> In the discussion for [1] the subject of the default cache and the way
>>>>> it affects configuration inheritance came up.
>>>>>
>>>>> My proposal is:
>>>>> - remove the default cache as a special cache altogether
>>>>> - CacheManager.getCache()  should return the named cache specified as

Re: [infinispan-dev] Default cache

[Paul Ferraro]

On Wed, Nov 30, 2016 at 9:13 AM, Tristan Tarrant <ttarr...@redhat.com> wrote:
> Some additional notes:
>
> - currently the XSD specifies the default-cache attribute on the
> cache-container element as required, but the parser doesn't enforce it.
> - A default ConfigurationBuilder is created for the default cache if one
> has not been specified
>
> My questions:
>
> 1. do we want the default cache to be optional or actually require it in
> the declarative configuration ?

In WildFly, default-cache has been optional since WF8.  The
cache-container used for hibernate 2LC, for example, does not have any
concept of a default-cache.  So, for us anyway, it makes sense for
default-cache to be optional.  However, we have the luxury of falling
back to Infinispan's default getCache() logic in the event that no
default-cache was specified.

> ** A: no enforcement. In this case requesting the default cache should
> print a warning about falling back to a "default" empty configuration.
>
> ** B: we don't require the user to specify a default cache in the
> configuration, but invoking getCache() will throw an exception.
>
> ** C: enforce it, although this will break all those XML files who
> haven't specified it.
>
> My preference is to use the namespace version and go for the A approach
> for < 9.0 and the B approach otherwise.

I think that makes sense.

> 2. currently, requesting a named cache for which a configuration hasn't
> been defined implicitly creates the cache by using the default
> configuration as a template.
>
> ** A: continue as is
>
> ** B: continue to implicitly create a cache, but use an empty
> configuration instead of using the default configuration, as this has
> been the source of confusion among users. Also print a warning.
>
> ** C: do not create caches unless a configuration has been explicitly
> provided.
>
> My preference is to use the namespace version and go for the A approach
> for < 9.0 and the C approach otherwise.

Agreed.

> Unfortunately the namespace version trick doesn't work for programmatic
> configurations. Probably we should add a boolean flag on the
> GlobalConfigurationManager (e.g. implicitCacheCreation) which defaults
> to false (because that's the "new order") but allows switching to the
> old behaviour if needed.
>
> In any case I'd like to also introduce a JCache-like createCache() API

I think it would be best/cleanest if caches created via this API are
anonymous (i.e. not managed by the cache manager or made accessible
via getCache(String)).  That way there is no ambiguity about who is
meant to manage the lifecycle (user vs container).

> Tristan
>
> On 10/11/16 13:20, Paul Ferraro wrote:
>> +1000
>>
>> This is precisely how we've setup cache manager semantics in WildFly
>> (since AS7):
>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/spi/src/main/java/org/wildfly/clustering/infinispan/spi/CacheContainer.java
>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/DefaultCacheContainer.java
>>
>> I'd love to be able to drop this.
>>
>> Paul
>>
>> On Thu, Nov 10, 2016 at 3:38 AM, Tristan Tarrant <ttarr...@redhat.com> wrote:
>>> In the discussion for [1] the subject of the default cache and the way
>>> it affects configuration inheritance came up.
>>>
>>> My proposal is:
>>> - remove the default cache as a special cache altogether
>>> - CacheManager.getCache()  should return the named cache specified as
>>> default in the configuration.
>>> - the programmatic GlobalConfigurationBuilder/GlobalConfiguration should
>>> have the notion of the default named cache (currently this is handled in
>>> the parser)
>>> - Retrieving the cache named "___defaultcache" should actually retrieve
>>> the above named cache
>>>
>>> Opinions ?
>>>
>>> Tristan
>>>
>>> [1] https://github.com/infinispan/infinispan/pull/4631
>>> --
>>> Tristan Tarrant
>>> Infinispan Lead
>>> JBoss, a division of Red Hat
>>> ___
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Default cache

[Paul Ferraro]

+1000

This is precisely how we've setup cache manager semantics in WildFly
(since AS7):
https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/spi/src/main/java/org/wildfly/clustering/infinispan/spi/CacheContainer.java
https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/DefaultCacheContainer.java

I'd love to be able to drop this.

Paul

On Thu, Nov 10, 2016 at 3:38 AM, Tristan Tarrant  wrote:
> In the discussion for [1] the subject of the default cache and the way
> it affects configuration inheritance came up.
>
> My proposal is:
> - remove the default cache as a special cache altogether
> - CacheManager.getCache()  should return the named cache specified as
> default in the configuration.
> - the programmatic GlobalConfigurationBuilder/GlobalConfiguration should
> have the notion of the default named cache (currently this is handled in
> the parser)
> - Retrieving the cache named "___defaultcache" should actually retrieve
> the above named cache
>
> Opinions ?
>
> Tristan
>
> [1] https://github.com/infinispan/infinispan/pull/4631
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] JGroups 4.0.0.Alpha1

[Paul Ferraro]

The problem isn't modifying the WF API to return a narrower type. We
can certainly do that. The problem is that existing applications
expect a org.wildfly.clustering.jgroups.ChannelFactory to return an
org.jgroups.Channel.  When they upgrade to WF11, they should get a
deprecation warning, not a NoClassDefFoundError. Eventually, we can
break their application, as they would have been sufficiently warned
already.  I'm sure there are JGroups users that will be in the same
boat.

On Tue, Aug 23, 2016 at 11:08 AM, Bela Ban <b...@redhat.com> wrote:
> Oh shoot, didn't know Channel was referenced directly!
>
> I assume you're upgrading JGroups only on a new major version of Wildfly,
> aren't you? Then, returning a JChannel instead of a Channel shouldn't be an
> issue, should it?
>
>
> On 23/08/16 16:01, Paul Ferraro wrote:
>>
>> Bela,
>>
>> Are you sure you want to drop the Channel interface [1] without any
>> deprecation?  WildFly references the Channel interface in public user
>> API [1].  I can certainly narrow the type for WF11, but this will
>> break user applications unexpectedly.
>>
>> Paul
>>
>> [1] https://issues.jboss.org/browse/JGRP-2018
>> [2]
>> https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/api/src/main/java/org/wildfly/clustering/jgroups/ChannelFactory.java
>>
>> On Tue, Aug 23, 2016 at 7:23 AM, Bela Ban <b...@redhat.com> wrote:
>>>
>>> Most API changes have been done, 12 issues left. I expect the final
>>> release
>>> in October.
>>>
>>> Note that JGroups-4.0.0-SNAPSHOT is also generated (on every change,
>>> IIRC).
>>>
>>> Feedback appreciated!
>>>
>>> [1] http://belaban.blogspot.ch/2016/08/jgroups-400alpha1-released.html
>>>
>>> --
>>> Bela Ban, JGroups lead (http://www.jgroups.org)
>>>
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] JGroups 4.0.0.Alpha1

[Paul Ferraro]

Bela,

Are you sure you want to drop the Channel interface [1] without any
deprecation?  WildFly references the Channel interface in public user
API [1].  I can certainly narrow the type for WF11, but this will
break user applications unexpectedly.

Paul

[1] https://issues.jboss.org/browse/JGRP-2018
[2] 
https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/api/src/main/java/org/wildfly/clustering/jgroups/ChannelFactory.java

On Tue, Aug 23, 2016 at 7:23 AM, Bela Ban  wrote:
> Most API changes have been done, 12 issues left. I expect the final release
> in October.
>
> Note that JGroups-4.0.0-SNAPSHOT is also generated (on every change, IIRC).
>
> Feedback appreciated!
>
> [1] http://belaban.blogspot.ch/2016/08/jgroups-400alpha1-released.html
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Infinispan URL format

[Paul Ferraro]

This also fits nicely with the JCache API, where a CacheProvider is
expected to express a connection to a CacheManager as a URI.

On Mon, May 30, 2016 at 3:46 AM, Tristan Tarrant  wrote:
> In the past there has been talk of representing a connection to
> Infinispan using a URL, in particular for HotRod.
> The Hibernate OGM team is now working on adding NoSQL datasources to
> WildFly, and they've asked for they should represent connections to
> various of these.
>
> For Hot Rod:
>
> infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]
>
> The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
> currently support this, so this is forward-looking).
> Obviously we will support all of the HotRod properties for specifying
> things like security, etc.
>
> For Embedded:
>
> infinispan:embedded:file://path/to/config.xml (for specifying an
> external config file)
> infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
> in JNDI)
> infinispan:embedded: (configuration specified as properties)
>
> For the latter, we also need to be able to represent an infinispan
> configuration using properties with a simple mapping to XML
> elements/attributes, e.g.
>
> cache-manager.local-cache.mycache.eviction.size=1000
>
>
> Comments are welcome
>
> Tristan
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] JCache integration with Wildfly provided configuration

[Paul Ferraro]

I see no reason why your producer wouldn't work - however, 
JCacheManager.close() will attempt to close the EmbeddedCacheManager.  You 
shouldn't do that.  The server manages the lifecycle of that resource.

- Original Message -
 From: Christian Beikov christ...@sweazer.com
 To: infinispan-dev@lists.jboss.org
 Sent: Monday, August 17, 2015 3:48:11 PM
 Subject: Re: [infinispan-dev] JCache integration with Wildfly provided
 configuration
 
 Thanks for the quick answer!
 
 Could you maybe tell me if what I did is ok? So far I don't seem to have
 a problem with the following solution.
 I put my cache configuration into a custom cache container of my
 standalone.xml and inject the cache container just to produce a JSR 107
 CacheManager like that:
 
 @Singleton
 public class ClusteredCacheManagerProducer {
 
  @Resource(lookup = java:jboss/infinispan/container/app)
  private EmbeddedCacheManager cacheManager;
 
  @Produces
  @ClusteredCache
  @ApplicationScoped
  public CacheManager produceJcacheCacheManager() {
  return new
 org.infinispan.jcache.JCacheManager(URI.create(app), cacheManager,
 Caching.getCachingProvider());
  }
 
  public void dispose(@Disposes @ClusteredCache CacheManager
 jcacheManager) {
  jcacheManager.close();
  }
 }
 
 Do you see anything problematic with that approach?
 
 Regards,
 Christian
 
 Am 11.08.2015 um 14:29 schrieb Paul Ferraro:
  - Original Message -
  From: Christian Beikov christ...@sweazer.com
  To: infinispan-dev@lists.jboss.org
  Sent: Sunday, August 9, 2015 12:02:13 PM
  Subject: [infinispan-dev] JCache integration with Wildfly provided
 configuration
 
  Hello,
 
  I am using Infinispan 7.2.3.Final within Wildfly 9.0.1 and I would like to
  use the JCache integration but I struggle a bit.
 
  I configured the JGroups subsystem in the standalone.xml of my Wildfly
  installation to enable clustering of Infinispan caches. That works as
  expected, but I wasn't sure how I would have my caches clustered too. I
  thought of some possible solutions but they both aren't really what I am
  looking for.
 
 
   1. Put the cache container configuration into standalone.xml
   2. Copy the JGroups configuration and create a new transport in a
   custom
   infinispan configuration
 
  When doing 1. I can't really use the JCache integration because there is
  no
  way to tell the caching provider, that I want a CacheManager for a
  specific
  cache container. If you would recommend doing 1. then it would be nice if
  the caching provider would not only accept file URIs, but also something
  like JNDI names. By doing that, I could reference existing cache
  containers
  which at least solves the problem with the JCache integration. Still I
  would
  prefer option 2. because I wouldn't have to change the standalone.xml
  every
  time I add a cache.
  The trouble with JCache integration into WildFly is that JCache is not an
  EE spec - and lacks any details for how cache resources should be managed
  by a container - or how a user would go about accessing container managed
  caches.  Nor is there any concept of sharing cache resources between
  applications (i.e. each manages the cache lifecycle manually) - or about
  isolation of cache entries beyond ClassLoader.  The API itself couples
  your code to a specific JCache implementation, since the URI of a cache
  manager is, by nature, provider specific.
  Consequently, we've deferred integrating JCache into WildFly until it's
  next evolution (i.e. 1.1/2.0) - or unless it somehow gets pulled into EE8.
 
  Consequently, if you really want to use the JCache API, you'll have to
  stick with option #2 for now.
 
  When doing 2. I can use the infinispan configuration file as URI when
  creating the cache manager so the JCache integration works without a
  problem. The only thing that is bothering me is, that I have to copy the
  JGroups configuration to have a separate transport for my applications
  cache
  container. I can't seem to reference the transport that I configured in
  the
  standalone.xml nor does it default to that. I would really like to reuse
  the
  JGroup channel that is already established.
  Infinispan requires a separate jgroups channel per cache manager - this is
  a limitation of Infinispan itself.  The only means of changing this is via
  a custom Transport implementation (as we do in WildFly).
  WildFly works around this limitation by providing Infinispan with a unique
  ForkChannel using a common JChannel.  You might try configuring Infinispan
  with a custom transport based on the implementation from WildFly.  See:
  https://github.com/wildfly/wildfly/blob/9.0.1.Final/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/ChannelTransport.java
 
  What I would like to know is, whether there is a possibility to make use
  of
  the JGroups configuration I did in the standalone.xml. If there isn't

Re: [infinispan-dev] JCache integration with Wildfly provided configuration

[Paul Ferraro]

- Original Message -
 From: Christian Beikov christ...@sweazer.com
 To: infinispan-dev@lists.jboss.org
 Sent: Sunday, August 9, 2015 12:02:13 PM
 Subject: [infinispan-dev] JCache integration with Wildfly provided
 configuration
 
 Hello,
 
 I am using Infinispan 7.2.3.Final within Wildfly 9.0.1 and I would like to
 use the JCache integration but I struggle a bit.
 
 I configured the JGroups subsystem in the standalone.xml of my Wildfly
 installation to enable clustering of Infinispan caches. That works as
 expected, but I wasn't sure how I would have my caches clustered too. I
 thought of some possible solutions but they both aren't really what I am
 looking for.
 
 
 1. Put the cache container configuration into standalone.xml
 2. Copy the JGroups configuration and create a new transport in a custom
 infinispan configuration
 
 When doing 1. I can't really use the JCache integration because there is no
 way to tell the caching provider, that I want a CacheManager for a specific
 cache container. If you would recommend doing 1. then it would be nice if
 the caching provider would not only accept file URIs, but also something
 like JNDI names. By doing that, I could reference existing cache containers
 which at least solves the problem with the JCache integration. Still I would
 prefer option 2. because I wouldn't have to change the standalone.xml every
 time I add a cache.

The trouble with JCache integration into WildFly is that JCache is not an EE 
spec - and lacks any details for how cache resources should be managed by a 
container - or how a user would go about accessing container managed caches.  
Nor is there any concept of sharing cache resources between applications (i.e. 
each manages the cache lifecycle manually) - or about isolation of cache 
entries beyond ClassLoader.  The API itself couples your code to a specific 
JCache implementation, since the URI of a cache manager is, by nature, provider 
specific.
Consequently, we've deferred integrating JCache into WildFly until it's next 
evolution (i.e. 1.1/2.0) - or unless it somehow gets pulled into EE8.

Consequently, if you really want to use the JCache API, you'll have to stick 
with option #2 for now.

 When doing 2. I can use the infinispan configuration file as URI when
 creating the cache manager so the JCache integration works without a
 problem. The only thing that is bothering me is, that I have to copy the
 JGroups configuration to have a separate transport for my applications cache
 container. I can't seem to reference the transport that I configured in the
 standalone.xml nor does it default to that. I would really like to reuse the
 JGroup channel that is already established.

Infinispan requires a separate jgroups channel per cache manager - this is a 
limitation of Infinispan itself.  The only means of changing this is via a 
custom Transport implementation (as we do in WildFly).
WildFly works around this limitation by providing Infinispan with a unique 
ForkChannel using a common JChannel.  You might try configuring Infinispan with 
a custom transport based on the implementation from WildFly.  See:
https://github.com/wildfly/wildfly/blob/9.0.1.Final/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/ChannelTransport.java

 What I would like to know is, whether there is a possibility to make use of
 the JGroups configuration I did in the standalone.xml. If there isn't, what
 should I do when wanting to cluster my caches? Just go with option 1?

Not without customization, see above.

 Regards,
 Christian Beikov
 
 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Is it time to reduce the complexity of the CacheManager?

[Paul Ferraro]

- Original Message -
 From: Sanne Grinovero sa...@infinispan.org
 To: infinispan -Dev List infinispan-dev@lists.jboss.org
 Sent: Thursday, February 19, 2015 11:46:11 AM
 Subject: [infinispan-dev] Is it time to reduce the complexity of the  
 CacheManager?
 
 All,
 at  the beginning of time, the expectation was that an application
 server (aka WildFly) would have a single CacheManager, and different
 applications would define their different Cache configuration on this
 app-server singleton.
 
 In that primitive world that sounded reasonable, as system
 administrators wouldn't want to manage firewalls and port assignments
 for a new Transport for each deployed application.
 
 Then the complexities came:
  - deployments are asymmetric compared to the application server
  - each deployment has its own ClassLoader
  - deployments start/stop independently from each other
 
 At that point a considerable investment was made to get lazily
 starting Caches, per-Cache sets of Externalizer(s) to isolate
 classloaders, ClassLoader-aware Cache decorators, up to the recently
 introduced Cache-dependency rules for stopping dependant Caches last.
 
 Not to mention we have now a complex per-Cache View handling, which
 results in performance complexities such as ISPN-4842.
 
 There are some more complexities coming:
 Hibernate OGM wishes to control the context of deserialization - this
 is actually an important optimisation to keep garbage production under
 control, but also applications might want to register custom RPC
 commands; this has been a long standing problem for Search (among
 others).
 Infinispan Query does have custom RPC commands, and this just happens
 to work because the Infinispan core module has an explicit dependency
 to query.. but that's a twisted dependency scheme, as the module would
 need to list each possible extension point: it's not something you can
 do for all projects using it.
 
 Interestingly enough, there is a very simple solution which wipes out
 all of the above complexity, and also resolves some pain points:
 today the app server supports the FORK protocol from JGroups, so we
 can get rid of the idea of a single CacheManager per appserver, and
 create one per classloader and *within* the classloader.
 
 By doing so, we can delete all code about per-Cache classloaders,

+1
This was something that was originally needed in AS6, but was made obsolete by 
the use of ModularClassResolver in AS7 and later.

 remove the CacheView concept, 

-1
So long as there is no such thing as a FORK view, I don't think we can get rid 
of Cache views - all you would succeed in doing is replacing it with a cache 
manager view (which would be equivalent to the FORK view).  However, I think 
the argument can be made that a cache manager vieww

 and also allow the deployment (the
 application) which is needing caching services to register whatever it
 wants.
 It could register custom interceptors, commands, externalizers,
 CacheStore(s), etc.. without pain.
 
 Finally, we could get rid of the concept that Caches start lazily. I'd
 change to a simplified lifecycle which expects the CacheManager to
 initialize, then allows Cache configurations to be defined, and then
 it all starts atomically.
 At that point, you'd not even be responsible anymore for complex
 dependency resolutions across caches.

This makes sense - WildFly has its own mechanism for handling the lifecycle of 
dependent caches.

 I'd hope this would allow OGM to get the features it needs, and also
 significantly simplify the definition of boot process for any user,
 not least it should simplify quite some code which is now being
 maintained.
 
 A nice follow-up task would be that WildFly would need to be able to
 pick up some configuration file from the deployment and inject a
 matching CacheManager, so this requires a bit of cooperation with the
 app server team, and an agreement on a conventional configuration
 name.
 This should be done by WildFly (and not the app), so that the user
 deployment can lookup the CacheManager by JNDI without needing to
 understand how to wire things up in the FORK channel.

I have to ask, if the proposal is to create a 1:1 relationship between cache 
and cache manager, and to also link their lifecycle - why are these separate 
objects/concepts at all?

 I also believe this is a winner from usability point of view, as many
 of the troubles I see in forums and customers are about how do I
 start this up?. Remember our guides essentially teach you to either
 take the AS CacheManager, or to start your own. Neither of those are
 the optimal solution, and people get in trouble.
 
 WDYT?
 
 Sanne
 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev
 
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org

Re: [infinispan-dev] Clustering standalone Infinispan w/ WF running Infinispan

[Paul Ferraro]

The only other obvious alternative of which I can think is to actually start 
the application which uses embedded Infinispan using jboss-modules.
That way you don't need to hack the behavior of ModularClassResolver.

- Original Message -
 From: Tristan Tarrant ttarr...@redhat.com
 To: Stelios Koussouris stkou...@redhat.com
 Cc: Kurt T Stam kurt.s...@jboss.com, infinispan -Dev List 
 infinispan-dev@lists.jboss.org, Richard
 Achmatowicz rachm...@redhat.com
 Sent: Thursday, October 2, 2014 9:21:07 AM
 Subject: Re: [infinispan-dev] Clustering standalone Infinispan w/ WF running 
 Infinispan
 
 I have successfully created a hybrid cluster between an application
 using Infinispan in embedded mode and an Infinispan server by doing the
 following on the embedded side:
 
 - use a JGroups Channel wrapped in a MuxHandler
 - use a custom class resolver which simulates (or rather... hacks) the
 behaviour of the ModularClassResolver when not using modules
 
 You can find the code at my personal GitHub repo:
 
 https://github.com/tristantarrant/infinispan-playground/tree/master/src/main/java/net/dataforte/infinispan/hybrid
 
 suggestions and improvements are welcome.
 
 Tristan
 
 On 30/09/14 10:01, Stelios Koussouris wrote:
  Hi,
 
  To give a bit of context on this. We are doing a POC where the customer
  wishes to utilize JDG to speed up their application. We need (due to some
  customer requirements) to cluster
  EMBEDDED JDG (infinispan library mode) with REMOTE JDG (Infinispan Server)
  nodes. The infinispan jars should be the same as they are only libraries
  and they
  are on the same version. However, during clustering of the caches we
  started seeing errors which looked like there were due to the fact that
  the clustering of the caches contained different
  info between the 2 types of cache instantiation (embedded vs server).
 
  The result was to for a suggestion to create our own MuxChannel (I don't
  know if we have any other alternatives at this stage to cluster embedded
  with server infinispan caches) but at the moment we are facing
  https://gist.github.com/skoussou/5edc5689446b67f85ae8
 
  Regards,
 
  Stylianos Kousouris
  Red Hat Middleware Consultant
 
  - Original Message -
  From: Tristan Tarrant ttarr...@redhat.com
  To: infinispan -Dev List infinispan-dev@lists.jboss.org, Kurt T Stam
  kurt.s...@jboss.com
  Cc: Stelios Koussouris stkou...@redhat.com, Richard Achmatowicz
  rachm...@redhat.com
  Sent: Tuesday, 30 September, 2014 8:02:27 AM
  Subject: Re: [infinispan-dev] Clustering standalone Infinispan w/ WF
  running Infinispan
 
  I don't know what Kurt is doing, but Stelios is attempting to cluster an
  application using embedded Infinispan deployed within WF together with
  an Infinispan Server instance.
  The application is managing its own caches, and therefore it is not
  interacting with the underlying Infinispan and JGroups subsystems in WF.
  Infinispan Server uses its Infinispan and JGroups subsystems (which are
  forked from WF's) and therefore are using MuxChannels.
 
  I told Stelios to use a MuxChannel-wrapped Channel in his application
  and it solved part of the issue (he was initially importing the one
  included in the WF's jgroups subsystem, but now he's using his local
  copy), but now he has run into further problems and I believe what Paul
   Dennis have written might be correct.
 
  The code that configures this is in
  EmbeddedCacheManagerConfigurationService:
 
  GlobalConfigurationBuilder builder = new GlobalConfigurationBuilder();
  ModuleLoader moduleLoader = this.dependencies.getModuleLoader();
  builder.serialization().classResolver(ModularClassResolver.getInstance(moduleLoader));
 
  I don't know how you'd get a ModuleLoader from within a WF deployment,
  but I'm sure it can be done.
 
  Tristan
 
  On 29/09/14 18:57, Paul Ferraro wrote:
  You should not need to use a MuxChannel.  This would only be necessary if
  there are other EAP services sharing the channel.  Using a MuxChannel
  allows your standalone Infinispan instance to filter these irrelevant
  messages.  However, in JDG, there should be no other services other than
  Infinispan using the channel - hence the MuxChannel stuff is unnecessary.
 
  I think Dennis earlier response was spot on.  EAP/JDG configures it's
  cache managers using a ModularClassResolver (which includes a module name
  along with the class name when marshalling).  Your standalone Infinispan
  instances do not use this and therefore cannot make sense of the message
  body.
 
  Paul
 
  - Original Message -
  From: Kurt T Stam kurt.s...@jboss.com
  To: Stelios Koussouris stkou...@redhat.com, Radoslav Husar
  rhu...@redhat.com
  Cc: Galder Zamarreño gal...@redhat.com, Paul Ferraro
  paul.ferr...@redhat.com, Richard Achmatowicz
  rachm...@redhat.com, infinispan -Dev List
  infinispan-dev@lists.jboss.org
  Sent: Monday, September 29, 2014 11:39:59 AM
  Subject: Re: Clustering standalone Infinispan w/ WF running

Re: [infinispan-dev] Clustering standalone Infinispan w/ WF running Infinispan

[Paul Ferraro]

infinispan-core and its dependencies would need to be bundled as modules using 
the same module descriptors as the server.

- Original Message -
 From: Tristan Tarrant ttarr...@redhat.com
 To: infinispan -Dev List infinispan-dev@lists.jboss.org
 Cc: Kurt T Stam kurt.s...@jboss.com, Stelios Koussouris 
 stkou...@redhat.com, Richard Achmatowicz
 rachm...@redhat.com
 Sent: Thursday, October 2, 2014 10:38:21 AM
 Subject: Re: [infinispan-dev] Clustering standalone Infinispan w/ WF running 
 Infinispan
 
 But then the module identifier wouldn't make sense: if you are embedding
 infinispan-core.jar, it would definitely not send org.infinispan:main
 as module:slot, which is what server needs instead.
 
 Tristan
 
 
 On 02/10/14 16:06, Paul Ferraro wrote:
  The only other obvious alternative of which I can think is to actually
  start the application which uses embedded Infinispan using jboss-modules.
  That way you don't need to hack the behavior of ModularClassResolver.
 
  - Original Message -
  From: Tristan Tarrant ttarr...@redhat.com
  To: Stelios Koussouris stkou...@redhat.com
  Cc: Kurt T Stam kurt.s...@jboss.com, infinispan -Dev List
  infinispan-dev@lists.jboss.org, Richard
  Achmatowicz rachm...@redhat.com
  Sent: Thursday, October 2, 2014 9:21:07 AM
  Subject: Re: [infinispan-dev] Clustering standalone Infinispan w/ WF
  running Infinispan
 
  I have successfully created a hybrid cluster between an application
  using Infinispan in embedded mode and an Infinispan server by doing the
  following on the embedded side:
 
  - use a JGroups Channel wrapped in a MuxHandler
  - use a custom class resolver which simulates (or rather... hacks) the
  behaviour of the ModularClassResolver when not using modules
 
  You can find the code at my personal GitHub repo:
 
  https://github.com/tristantarrant/infinispan-playground/tree/master/src/main/java/net/dataforte/infinispan/hybrid
 
  suggestions and improvements are welcome.
 
  Tristan
 
  On 30/09/14 10:01, Stelios Koussouris wrote:
  Hi,
 
  To give a bit of context on this. We are doing a POC where the customer
  wishes to utilize JDG to speed up their application. We need (due to some
  customer requirements) to cluster
  EMBEDDED JDG (infinispan library mode) with REMOTE JDG (Infinispan
  Server)
  nodes. The infinispan jars should be the same as they are only libraries
  and they
  are on the same version. However, during clustering of the caches we
  started seeing errors which looked like there were due to the fact that
  the clustering of the caches contained different
  info between the 2 types of cache instantiation (embedded vs server).
 
  The result was to for a suggestion to create our own MuxChannel (I don't
  know if we have any other alternatives at this stage to cluster embedded
  with server infinispan caches) but at the moment we are facing
  https://gist.github.com/skoussou/5edc5689446b67f85ae8
 
  Regards,
 
  Stylianos Kousouris
  Red Hat Middleware Consultant
 
  - Original Message -
  From: Tristan Tarrant ttarr...@redhat.com
  To: infinispan -Dev List infinispan-dev@lists.jboss.org, Kurt T
  Stam
  kurt.s...@jboss.com
  Cc: Stelios Koussouris stkou...@redhat.com, Richard Achmatowicz
  rachm...@redhat.com
  Sent: Tuesday, 30 September, 2014 8:02:27 AM
  Subject: Re: [infinispan-dev] Clustering standalone Infinispan w/ WF
  running Infinispan
 
  I don't know what Kurt is doing, but Stelios is attempting to cluster an
  application using embedded Infinispan deployed within WF together with
  an Infinispan Server instance.
  The application is managing its own caches, and therefore it is not
  interacting with the underlying Infinispan and JGroups subsystems in WF.
  Infinispan Server uses its Infinispan and JGroups subsystems (which are
  forked from WF's) and therefore are using MuxChannels.
 
  I told Stelios to use a MuxChannel-wrapped Channel in his application
  and it solved part of the issue (he was initially importing the one
  included in the WF's jgroups subsystem, but now he's using his local
  copy), but now he has run into further problems and I believe what Paul
   Dennis have written might be correct.
 
  The code that configures this is in
  EmbeddedCacheManagerConfigurationService:
 
  GlobalConfigurationBuilder builder = new GlobalConfigurationBuilder();
  ModuleLoader moduleLoader = this.dependencies.getModuleLoader();
  builder.serialization().classResolver(ModularClassResolver.getInstance(moduleLoader));
 
  I don't know how you'd get a ModuleLoader from within a WF deployment,
  but I'm sure it can be done.
 
  Tristan
 
  On 29/09/14 18:57, Paul Ferraro wrote:
  You should not need to use a MuxChannel.  This would only be necessary
  if
  there are other EAP services sharing the channel.  Using a MuxChannel
  allows your standalone Infinispan instance to filter these irrelevant
  messages.  However, in JDG, there should be no other services other than
  Infinispan using the channel - hence

[infinispan-dev] Removal of ConfigurationBuilder.classLoader(...)

[Paul Ferraro]

It seems that the ability to associate a cache with a specific classloader has 
been removed in 7.0 by this commit:
https://github.com/infinispan/infinispan/commit/39a21a025db2e0f85019b93d09052b4772abbaa8

I don't fully understand the reason for the removal. WildFly previously relied 
on this mechanism to define the classloader from which Infinispan should load 
any classes when building its configuration.  In general, WF builds its 
configuration using object instances instead of class names, so normally this 
isn't a problem.  However, there isn't always such a mechanism (e.g. 
https://issues.jboss.org/browse/ISPN-3979)

However, now that ConfigurationBuilder.classloader(...) is gone, the 
classloader used to build a Configuration is effectively hardcoded (usually as 
this.getClass().getClassLoader()).

This directly affects the ability for a WildFly using to configure a cache with 
querying.  IndexingConfigurationBuilder.validate(...) previously used the 
configured classloader to validate that the query module is loadable.

https://github.com/infinispan/infinispan/blob/6.0.x/core/src/main/java/org/infinispan/configuration/cache/IndexingConfigurationBuilder.java#L141

However, this is now hardcoded to use the classloader that loaded the 
IndexingConfigurationBuilder class itself.

https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/configuration/cache/IndexingConfigurationBuilder.java#L183

The WF distribution uses distinct modules for infinispan-core vs 
infinispan-query.  Consequently, if your cache don't need querying, the query 
module is not loaded.  WF8 let the user configure a cache with query support 
via distributed-cache ... module=org.infinispan.query/.

Currently, however, the only way we can satisfy the validation logic in 
IndexingConfigurationBuilder.validate(...) is to bloat our core 
org.infinispan module with the infinispan-query module and its dependencies.  
I don't want to do that.  Is there some way we can re-enable the ability to 
configure a cache with a classloader that still satisfies the reasons for its 
original removal? GlobalConfigurationBuilder still supports the ability to 
configure a classloader, why remove this from ConfigurationBuilder?

That said, however, the IndexingConfigurationBuilder validation itself is 
wrong.  Ultimately, the infinispan-query module will be loaded by the 
classloader with which the GlobalConfiguration was built (i.e. the default 
classloader of the cache), so really, at the very least, the validation logic 
in IndexingConfigurationBuilder.validate(...) should reflect this.  I've opened 
https://issues.jboss.org/browse/ISPN-4639 to track this specific bug.

Thoughts?
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Infinispan 7.0 to Java 7

[Paul Ferraro]

As an EE7 application server, WF already requires Java SE 7.

On Wed, 2014-04-09 at 17:30 +0100, Mircea Markus wrote:
 Hi guys,
 
 Hibernate Search 5.0 is moving to Java 7 (besides others, because Lucene 4.8 
 does it).
 For us it makes a lot of sense to bring in HSearch 5/Lucene 4 rather soon, as 
 it's important for remote querying.
 How does that sound? 
 Paul, how does that fit with the WF integration?
 
 Cheers,


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

[infinispan-dev] Feature requests for 7.0

[Paul Ferraro]

Hey guys,

I have created a number of requests for features that I'd like to be
able to leverage for WildFly 9/10.  Can the appropriate component owners
(which I think is Dan in all cases) comment on the following issues?

The following issues prevent WF from leveraging Infinispan expiration:
* Expiration events from cache store
  https://issues.jboss.org/browse/ISPN-3064
* Group-based expiration
  https://issues.jboss.org/browse/ISPN-2916

Now that Infinispan eviction is safe for use by transactional caches,
there remain a few issues complicating the ability for WF to fully
leverage the eviction manager for passivation:
* Group-based eviction
  https://issues.jboss.org/browse/ISPN-4132
* Clustered eviction (this one is really only an inconvenience for those
of us using manual eviction since I can't use infinispan eviction)
  https://issues.jboss.org/browse/ISPN-4134

Optimizations:
* Enumerate cache keys for group
  https://issues.jboss.org/browse/ISPN-3900
* Unloadable Key2StringMapper
  https://issues.jboss.org/browse/ISPN-3979

Thanks,

Paul


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Design change in Infinispan Query

[Paul Ferraro]

On Wed, 2014-03-12 at 18:45 +0100, Galder Zamarreño wrote:
 On 05 Mar 2014, at 18:16, Mircea Markus mmar...@redhat.com wrote:
 
  Sanne came with a good follow up to this email, just some small 
  clarifications:
  
  On Mar 4, 2014, at 6:02 PM, Emmanuel Bernard emman...@hibernate.org wrote:
  
  If you have to do a map reduce for tasks so simple as age  18, I think 
  you system better have to be prepared to run gazillions of M/R jobs.
  
  I want to run a simple M/R job in the evening to determine who turns 18 
  tomorrow, to congratulate them. Once a day, not gazzilions of times, and 
  I don't need to index the age filed just for that. Also when it comes to 
  Map/Reduce, the drawback of holding all the data in a single cache is 
  two-folded:
  - performance: you iterate over the data that is not related to your 
  query. 
  
  If the data are never related (query wise), then we are in the database 
  split category. Which is fine. But if some of your queries are related, 
  what do you do? Deny the user the ability to do them?
  
  Here's where cross-site query would have been used. As Sanne suggested 
  (next post) these limitations overcome the advantages.
  
  
  - programming model: the Map/Reduce implementation has a dependency on 
  both Dog and Person. If I add Cats to the cache, I'll need to update the 
  M/R code to be aware of that as well. Same if I rename/remove Dog. Not 
  nice.
  
  Well it’s called type safety, some people find it good ;)
  
  If anything, this model reduces type safety and reusability. E.g. say you 
  want a M/R task to see how many Persons speak French. With the single cache 
  model(both Dog and Person int he CacheString, Mammal) it would look 
  something like:
  
  a)
  //pseudocode
  map (String k, Mammal value) {  
   if (value instanceof Person)) { //this is the ugly part
  if  (((Person)value).speaks(French)) ...
   } else {
  //ignore it, it's an Dog
   }
  }
  
  Same thing written for a CacheString, Person:
  
  b)
  map (String k, Person value) {
if  (value.speaks(French)) ...
  }
  
  I don't think people would prefer writing a) instead of b) ;)
 
 It’s a pity that having discussed in Mallorca and having referenced a fair 
 few times already, you could not think of an option based on what Paul 
 suggsted in https://issues.jboss.org/browse/ISPN-3640
 
 Here’s my attempt:
 
 Cache?, ? cache = …;
 ValueFilter filter = … // filter would check those values that are persons...
 CacheString, Person view = cache.filter(filter);
 view.map(String k, Person value) {
 ...
 }
 
 Paul referred to per key type filters, but maybe per value type filters, such 
 as the one I did here, might be useful.

We could also generalize KeyFilter to something like:

public interface Filter {
boolean accepts(Object key, Object value);
}

Infinispan could ship some simple default implementations that filter
based on a specific key type, value type, or both.

e.g.

Cache?, ? cache = ...;
CacheString, Integer view = cache.filter(new KeyValueTypeFilter(String.class, 
Integer.class));
view.addListener(...);  // Listens only to events accepted by filter
for (Map.EntryString, Integer entry: view.entrySet()) {
// No casting necessary!
}

where KeyValueTypeFilter looks like:

public class KeyValueTypeFilter implements Filter {
private Class? keyType;
private Class? valueType;
public KeyValueTypeFilter(Class? keyType, Class? valueType) {
this.keyType = keyType;
this.valueType = valueType;
}

@Override
public boolean accepts(Object key, Object value) {
return this.keyType.isInstance(key)  this.valueType.isInstance(value);
}
}

 Cheers,
 
 
  
  
  Cheers,
  -- 
  Mircea Markus
  Infinispan lead (www.infinispan.org)
  
  
  
  
  
  ___
  infinispan-dev mailing list
  infinispan-dev@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/infinispan-dev
 
 
 --
 Galder Zamarreño
 gal...@redhat.com
 twitter.com/galderz
 
 Project Lead, Escalante
 http://escalante.io
 
 Engineer, Infinispan
 http://infinispan.org
 


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] wf config

[Paul Ferraro]

Ooops.  That's a bug - I'll submit a PR momentarily.

On Wed, 2014-01-29 at 13:08 +0100, Ales Justin wrote:
 I'm looking at current WildFly integration.
 
 In CacheAdd I see this code:
 
 if ((lockingMode == LockingMode.OPTIMISTIC)  (isolationLevel == 
 IsolationLevel.REPEATABLE_READ)) {
 builder.locking().writeSkewCheck(true);
 }
 
 but then locking has this validation:
 
public void validate() {
   if (writeSkewCheck) {
  if (isolationLevel != IsolationLevel.REPEATABLE_READ)
 throw new CacheConfigurationException(Write-skew checking only 
 allowed with REPEATABLE_READ isolation level for cache);
  if (transaction().lockingMode != LockingMode.OPTIMISTIC)
 throw new CacheConfigurationException(Write-skew checking only 
 allowed with OPTIMISTIC transactions);
  if (!versioning().enabled || versioning().scheme != 
 VersioningScheme.SIMPLE)
 throw new CacheConfigurationException(
   Write-skew checking requires versioning to be enabled and 
 versioning scheme 'SIMPLE' to be configured);
 
 Yet there is no versioning handling in WF subsystem.
 (just listing what's supported)
 
 private void parseCacheElement(XMLExtendedStreamReader reader, Element 
 element, ModelNode cache, ListModelNode operations) throws 
 XMLStreamException {
 switch (element) {
 case LOCKING: {
 case TRANSACTION: {
 case EVICTION: {
 case EXPIRATION: {
 case STORE: {
 case FILE_STORE: {
 case STRING_KEYED_JDBC_STORE: {
 case BINARY_KEYED_JDBC_STORE: {
 case MIXED_KEYED_JDBC_STORE: {
 case REMOTE_STORE: {
 case INDEXING: {
 default: {
 throw ParseUtils.unexpectedElement(reader);
 }
 
 How do you expect the user to get pass the validation,
 where you magically enable writeSkewCheck?
 
 -Ales
 
 
 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] wf config

[Paul Ferraro]

FYI:
https://issues.jboss.org/browse/WFLY-2829
https://github.com/wildfly/wildfly/pull/5808

On Wed, 2014-01-29 at 08:42 -0500, Paul Ferraro wrote:
 Ooops.  That's a bug - I'll submit a PR momentarily.
 
 On Wed, 2014-01-29 at 13:08 +0100, Ales Justin wrote:
  I'm looking at current WildFly integration.
  
  In CacheAdd I see this code:
  
  if ((lockingMode == LockingMode.OPTIMISTIC)  (isolationLevel == 
  IsolationLevel.REPEATABLE_READ)) {
  builder.locking().writeSkewCheck(true);
  }
  
  but then locking has this validation:
  
 public void validate() {
if (writeSkewCheck) {
   if (isolationLevel != IsolationLevel.REPEATABLE_READ)
  throw new CacheConfigurationException(Write-skew checking only 
  allowed with REPEATABLE_READ isolation level for cache);
   if (transaction().lockingMode != LockingMode.OPTIMISTIC)
  throw new CacheConfigurationException(Write-skew checking only 
  allowed with OPTIMISTIC transactions);
   if (!versioning().enabled || versioning().scheme != 
  VersioningScheme.SIMPLE)
  throw new CacheConfigurationException(
Write-skew checking requires versioning to be enabled 
  and versioning scheme 'SIMPLE' to be configured);
  
  Yet there is no versioning handling in WF subsystem.
  (just listing what's supported)
  
  private void parseCacheElement(XMLExtendedStreamReader reader, Element 
  element, ModelNode cache, ListModelNode operations) throws 
  XMLStreamException {
  switch (element) {
  case LOCKING: {
  case TRANSACTION: {
  case EVICTION: {
  case EXPIRATION: {
  case STORE: {
  case FILE_STORE: {
  case STRING_KEYED_JDBC_STORE: {
  case BINARY_KEYED_JDBC_STORE: {
  case MIXED_KEYED_JDBC_STORE: {
  case REMOTE_STORE: {
  case INDEXING: {
  default: {
  throw ParseUtils.unexpectedElement(reader);
  }
  
  How do you expect the user to get pass the validation,
  where you magically enable writeSkewCheck?
  
  -Ales
  
  
  ___
  infinispan-dev mailing list
  infinispan-dev@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/infinispan-dev
 
 
 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Unit test for ISPN-3698 and more workarounds...

[Paul Ferraro]

Excellent.

I think this will do in the short term, but in the long term, I think we
need to revisit some of the finer points of the cache manager lifecycle,
especially within the context of Wildfly/EAP.

In Wildfly/EAP, 2 deployment thread can easily trigger a case where a
cache manager is restarted using the same GlobalConfiguration instance.

The root of the problem, I think, is that the GlobalConfiguration and
cache Configuration objects currently have references to
stateful/runtime objects like VersionAwareMarshaller.  I think this is a
bad idea.  Ideally, the GlobalConfiguration object would simply contain
a factory for creating instances of the marshaller.  The marshaller
instance would only be instantiated as part of the cache/cache manager
startup process.  This way, the same GlobalConfiguration object can be
use to create any number of cache managers.  That would make Wildfly/EAP
very happy.

Paul

On Wed, 2013-11-13 at 10:49 +0100, Galder Zamarreño wrote:
 On Nov 13, 2013, at 10:09 AM, Galder Zamarreño gal...@redhat.com wrote:
 
  Hey Paul,
  
  I've got a unit test for ISPN-3698 [1] [2].
  
  The test hangs when in cm1.getCache() at the end of the test. If you look 
  at the logs you'll find a load of NPEs like the one in the JIRA.
  
  If this is what you are doing, another thing that should work fine is 
  essentially rebuild the configurations when you start a new cache manager 
  and avoid using the configuration objects of a stopped cache manager. 
  
  The key thing here is that if you create a new instance of 
  GlobalConfigurationBuilder when you redeploy, it'll automatically create a 
  brand new instance of VersionAwareMarshaller, and that would get around the 
  issue.
  
  As long as the new global configuration has a reference to the old 
  VersionAwareMarshaller, you have the potential for the NPE (unless you do 
  some trick to reset VersionAwareMarshaller's defaultMarshaller instance).
  
  WRT the fix I proposed it yesterday, I've run it through our testsuite and 
  a fair few failures appear (~60), so think whether you can get around it 
  with a workaround like the one explained in this email. In the mean time 
  I'm trying to find a better fix within Infinispan itself.
 
 ^ The fix had some issues with those tests that rewire components, but I've 
 fixed that now and I'll send a PR right away.
 
 Cheers,
 
  
  Cheers,
  
  [1] https://issues.jboss.org/browse/ISPN-3698
  [2] https://gist.github.com/9d5ab3623f57ec8b23ee
  --
  Galder Zamarreño
  gal...@redhat.com
  twitter.com/galderz
  
  Project Lead, Escalante
  http://escalante.io
  
  Engineer, Infinispan
  http://infinispan.org
  
  
  ___
  infinispan-dev mailing list
  infinispan-dev@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/infinispan-dev
 
 
 --
 Galder Zamarreño
 gal...@redhat.com
 twitter.com/galderz
 
 Project Lead, Escalante
 http://escalante.io
 
 Engineer, Infinispan
 http://infinispan.org
 


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Supporting notifications for entries expired while in the cache store - ISPN-694

[Paul Ferraro]

On Wed, 2013-05-22 at 18:03 +0200, Galder Zamarreño wrote:
 On May 21, 2013, at 7:42 PM, Paul Ferraro paul.ferr...@redhat.com wrote:
 
  On Tue, 2013-05-21 at 17:07 +0200, Galder Zamarreño wrote:
  On May 6, 2013, at 2:20 PM, Mircea Markus mmar...@redhat.com wrote:
  
  
  On 3 May 2013, at 20:15, Paul Ferraro wrote:
  
  Is it essential?  No - but it would simplify things on my end.
  If Infinispan can't implement expiration notifications, then I am forced
  to use immortal cache entries and perform expiration myself.  To do
  this, I have to store meta information about the cache entry along with
  my actual cache values, which normally I would get for free via mortal
  cache entries.
  
  In the scope of 5.2, what galder suggested was to fully support 
  notifications for the entries in memory. In order to fully support your 
  use case you'd need to add some code to trigger notifications in the 
  cache store as well - I think that shouldn't be too difficult. What cache 
  store implementation are you using any way?
  
  ^ Personally, I'd do in-memory entry expiration notifications for 5.2, and 
  I'd leave cache store based entry expiration for 6.0, when we'll revisit 
  cache store API, and we can address cache store based entry expiration 
  notification properly.
  
  Agree everyone?
  
  Thanks fine.
  Just to clarify, the end result is that an expiration notification would
  only ever be emitted on 1 node per cache entry, correct?  That is to
  say, for a given expired cache entry, the corresponding isOriginLocal()
  would only ever return true on one node, yes?  I just want to make sure
  that each node won't emit a notification for the same cache entry that
  was discovered to have expired.
 
 ^ H, if you want it to work that way it might need some thinking, and it 
 could be expensive to achieve...
 
 If the expiration happens when an entry is retrieved from the cache and this 
 is expired, it's local. So, the way expiration will occur is that when each 
 node accesses the entry and is expired, it will send a notification to any 
 listener available locally indicating that the origin is local. The same 
 thing happens when eviction calls purgeExpired.

That's precisely what I meant, actually.

 The advantage here is that expiration is local, and hence fast. No need to 
 communicate with other nodes. Your suggestion might require nodes to interact 
 with each other for expiration to find out where the expiration started to be 
 differentiate between originLocal=true/false. I'm not sure we want to do this…

In our use case, the entry retrieval is done within the context of
pessimistic locking, so a node would already have exclusive access to
the cache key.  If I understand you correctly, this would inherently
prevent multiple local expiration notifications from every node.  In
this case, if a concurrent entry retrieval occurred on some other node -
by the time that node got access to the lock, it would already have been
removed from the cache store, thus no local expiration notification
would be emitted from that node, correct?

My concern is about any kind of auto-purging of expired cache store
entries within the cache store itself.  I imagine this would operate
outside the context of any such locking, thus the potential for local
expiration notifications on multiple nodes for the same cache entry.

 Cheers,
 
  
  
  So, it would be nice to have.  If I have to wait for 6.0 for this,
  that's ok.
  
  On Thu, 2013-05-02 at 17:03 +0200, Galder Zamarreño wrote:
  Hi,
  
  Re: https://issues.jboss.org/browse/ISPN-694
  
  We've got a little problem here. Paul requires that entries that might
  have been expired while in the cache store, when loaded, we send
  expiration notifications for them.
  
  The problem is that expiration checking is currently done in the
  actual cache store implementations, which makes supporting this (even
  outside the purgeExpired business) specific to each cache store. Not
  ideal.
  
  The alternative would be for CacheLoaderInterceptor to load, do the
  checks and then remove the entries accordingly. The big problem here
  is that you're imposing a way to deal with expiration handling for all
  cache store implementations, and some might be able to do these checks
  and removals in a more efficient way if they were left to do it
  themselves. For example, having to load all entries and then decide
  which are to expire might require a lot of work, instead of
  potentially communicating directly with the cache store (imagine a
  remote cache store…) and asking it to return all the entries filtered
  by those whose expiry has not expired. 
  
  However, even if a cache store can do that, it would lead to loading
  only those entries not expired, but then how do you send the
  notifications if those expired entries have been filtered out? You
  probably need multiple load methods here...
  
  @Paul, do you really need this for your use case?
  
  The simplest

Re: [infinispan-dev] Supporting notifications for entries expired while in the cache store - ISPN-694

[Paul Ferraro]

On Tue, 2013-05-21 at 17:07 +0200, Galder Zamarreño wrote:
 On May 6, 2013, at 2:20 PM, Mircea Markus mmar...@redhat.com wrote:
 
  
  On 3 May 2013, at 20:15, Paul Ferraro wrote:
  
  Is it essential?  No - but it would simplify things on my end.
  If Infinispan can't implement expiration notifications, then I am forced
  to use immortal cache entries and perform expiration myself.  To do
  this, I have to store meta information about the cache entry along with
  my actual cache values, which normally I would get for free via mortal
  cache entries.
  
  In the scope of 5.2, what galder suggested was to fully support 
  notifications for the entries in memory. In order to fully support your use 
  case you'd need to add some code to trigger notifications in the cache 
  store as well - I think that shouldn't be too difficult. What cache store 
  implementation are you using any way?
 
 ^ Personally, I'd do in-memory entry expiration notifications for 5.2, and 
 I'd leave cache store based entry expiration for 6.0, when we'll revisit 
 cache store API, and we can address cache store based entry expiration 
 notification properly.
 
 Agree everyone?

Thanks fine.
Just to clarify, the end result is that an expiration notification would
only ever be emitted on 1 node per cache entry, correct?  That is to
say, for a given expired cache entry, the corresponding isOriginLocal()
would only ever return true on one node, yes?  I just want to make sure
that each node won't emit a notification for the same cache entry that
was discovered to have expired.

  
  So, it would be nice to have.  If I have to wait for 6.0 for this,
  that's ok.
  
  On Thu, 2013-05-02 at 17:03 +0200, Galder Zamarreño wrote:
  Hi,
  
  Re: https://issues.jboss.org/browse/ISPN-694
  
  We've got a little problem here. Paul requires that entries that might
  have been expired while in the cache store, when loaded, we send
  expiration notifications for them.
  
  The problem is that expiration checking is currently done in the
  actual cache store implementations, which makes supporting this (even
  outside the purgeExpired business) specific to each cache store. Not
  ideal.
  
  The alternative would be for CacheLoaderInterceptor to load, do the
  checks and then remove the entries accordingly. The big problem here
  is that you're imposing a way to deal with expiration handling for all
  cache store implementations, and some might be able to do these checks
  and removals in a more efficient way if they were left to do it
  themselves. For example, having to load all entries and then decide
  which are to expire might require a lot of work, instead of
  potentially communicating directly with the cache store (imagine a
  remote cache store…) and asking it to return all the entries filtered
  by those whose expiry has not expired. 
  
  However, even if a cache store can do that, it would lead to loading
  only those entries not expired, but then how do you send the
  notifications if those expired entries have been filtered out? You
  probably need multiple load methods here...
  
  @Paul, do you really need this for your use case?
  
  The simplest thing to do might be to go for option 1, and let each
  cache store send notifications for expired entries for the moment, and
  then in 6.0 revise not only the API for purgeExpired, but also the API
  for load/loadAll() to find a way that, if any expiry listeners are in
  place, a different method can be called on the cache store that
  signals it to return all entries: both expired and non-expired, and
  then let the CacheLoaderInterceptor send notifications from a central
  location.
  
  Thoughts?
  
  Cheers,
  --
  Galder Zamarreño
  gal...@redhat.com
  twitter.com/galderz
  
  Project Lead, Escalante
  http://escalante.io
  
  Engineer, Infinispan
  http://infinispan.org
  
  
  
  ___
  infinispan-dev mailing list
  infinispan-dev@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/infinispan-dev
  
  Cheers,
  -- 
  Mircea Markus
  Infinispan lead (www.infinispan.org)
  
  
  
  
 
 
 --
 Galder Zamarreño
 gal...@redhat.com
 twitter.com/galderz
 
 Project Lead, Escalante
 http://escalante.io
 
 Engineer, Infinispan
 http://infinispan.org
 
 
 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] write-heavy performance degradation between 5.1 and 5.2

[Paul Ferraro]

Good summary Martin.  To this day, I'm not convinced there was ever any
performance regression - but throw some aberrant graphs at management
without sufficient context and things get escalated quickly...

One of the issues with testing across versions is considering the
baseline.  In the case of EAP 6.0 vs 6.1, the non-clustered performance
is actually faster in 6.1.  When this is the case, the cross version
performance comparison should really include a handicap for 6.1, meaning
that we shouldn't be comparing clustering throughput given the same
number of concurrent clients, but rather the clustering throughput given
the same clustering load, which in 6.1, is actually at a lower number
of clients than 6.0.  When considering the handicap, the perf numbers
are much more in line with the numbers I've seen from Infinispan 5.1 vs
5.2 directly.

On Tue, 2013-05-07 at 14:28 +0200, Martin Gencur wrote:
 Kind oftheir configuration is replicated  embedded cache + async 
 replication + batching + file store + passivation off + write-heavy
 
 We, indeed, do *not* test this configuration for regression (especially 
 the batching + file store + write-heavy). And even if we did, we 
 wouldn't spot the problem easily. The performance regression was 
 revealed in a client stress test where the number of clients is 
 gradually increased. The peak throughput in their tests was higher for 
 5.2 than for 5.1 - this was OK. They complained about the max. number of 
 clients that can be handled and the throughput after the peak (not 
 before it). And this has to do with JGroups tuning (thread pools etc.) 
 This is a very specific test case and issue and can be revealed only by 
 the client stress tests which are the most time consuming.
 
 Anyway, we'll try to incorporate this scenario into the regular 
 regression performance testing we're working on so that we catch these 
 problems sooner than the respective version of ISPN gets to AS.
 
 Martin
 
 
 Dne 2.5.2013 19:43, Galder Zamarreño napsal(a):
  My gut feeling is: AS uses some cache configuration that's affecting 
  performance and it's not currently in the test plan?
 
  Cheers,
 
  On May 2, 2013, at 12:41 PM, Radim Vansa rva...@redhat.com wrote:
 
  Hi, I've checked it on 4 nodes, stress test 15 minutes with 80% writes. 
  Both reads and writes have improved in 5.2
 
  READS/sec 247k - 263k
  WRITES/sec 4547 - 4771 (note: this is average, coordinator has about 2x 
  more writes as it is the lock owner for all locks in replicated mode)
  that makes
 
  Paul, how many operations within transaction do you use? The results above 
  are from single operation (put/get) per transaction (we have improvement 
  in TRANSACTIONS/sec 5655 - 5936 with this setting), I'll try to rerun 
  with more ops/transaction as well.
 
  Radim
 
  - Original Message -
  | From: Paul Ferraro paul.ferr...@redhat.com
  | To: Mircea Markus mmar...@redhat.com
  | Cc: infinispan infinispan-dev@lists.jboss.org, Paul Ferraro 
  pferr...@redhat.com
  | Sent: Wednesday, May 1, 2013 5:05:39 PM
  | Subject: Re: [infinispan-dev] write-heavy performance degradation 
  between5.1 and 5.2
  |
  | FYI - here's a summary of EAP 6.0 vs 6.1 performance:
  | https://bugzilla.redhat.com/attachment.cgi?id=741896
  |
  | and here's the relevant BZ:
  | https://bugzilla.redhat.com/show_bug.cgi?id=956988
  |
  | On Wed, 2013-05-01 at 15:55 +0100, Mircea Markus wrote:
  |  Hi Martin,
  | 
  |  Paul mentioned a severe degradation in performance between 5.1 and 5.2 
  for
  |  replicated + embedded + transactional + pessimistic caches, for
  |  write-heavy access. Do we have any tests we can run to check this?
  | 
  |  Cheers,
  |
  |
  | ___
  | infinispan-dev mailing list
  | infinispan-dev@lists.jboss.org
  | https://lists.jboss.org/mailman/listinfo/infinispan-dev
  |
  ___
  infinispan-dev mailing list
  infinispan-dev@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/infinispan-dev
 
  --
  Galder Zamarreño
  gal...@redhat.com
  twitter.com/galderz
 
  Project Lead, Escalante
  http://escalante.io
 
  Engineer, Infinispan
  http://infinispan.org
 
 
  ___
  infinispan-dev mailing list
  infinispan-dev@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/infinispan-dev
 


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Supporting notifications for entries expired while in the cache store - ISPN-694

[Paul Ferraro]

Is it essential?  No - but it would simplify things on my end.
If Infinispan can't implement expiration notifications, then I am forced
to use immortal cache entries and perform expiration myself.  To do
this, I have to store meta information about the cache entry along with
my actual cache values, which normally I would get for free via mortal
cache entries.

So, it would be nice to have.  If I have to wait for 6.0 for this,
that's ok.

On Thu, 2013-05-02 at 17:03 +0200, Galder Zamarreño wrote:
 Hi,
 
 Re: https://issues.jboss.org/browse/ISPN-694
 
 We've got a little problem here. Paul requires that entries that might
 have been expired while in the cache store, when loaded, we send
 expiration notifications for them.
 
 The problem is that expiration checking is currently done in the
 actual cache store implementations, which makes supporting this (even
 outside the purgeExpired business) specific to each cache store. Not
 ideal.
 
 The alternative would be for CacheLoaderInterceptor to load, do the
 checks and then remove the entries accordingly. The big problem here
 is that you're imposing a way to deal with expiration handling for all
 cache store implementations, and some might be able to do these checks
 and removals in a more efficient way if they were left to do it
 themselves. For example, having to load all entries and then decide
 which are to expire might require a lot of work, instead of
 potentially communicating directly with the cache store (imagine a
 remote cache store…) and asking it to return all the entries filtered
 by those whose expiry has not expired. 
 
 However, even if a cache store can do that, it would lead to loading
 only those entries not expired, but then how do you send the
 notifications if those expired entries have been filtered out? You
 probably need multiple load methods here...
 
 @Paul, do you really need this for your use case?
 
 The simplest thing to do might be to go for option 1, and let each
 cache store send notifications for expired entries for the moment, and
 then in 6.0 revise not only the API for purgeExpired, but also the API
 for load/loadAll() to find a way that, if any expiry listeners are in
 place, a different method can be called on the cache store that
 signals it to return all entries: both expired and non-expired, and
 then let the CacheLoaderInterceptor send notifications from a central
 location.
 
 Thoughts?
 
 Cheers,
 --
 Galder Zamarreño
 gal...@redhat.com
 twitter.com/galderz
 
 Project Lead, Escalante
 http://escalante.io
 
 Engineer, Infinispan
 http://infinispan.org
 


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] write-heavy performance degradation between 5.1 and 5.2

[Paul Ferraro]

FYI - here's a summary of EAP 6.0 vs 6.1 performance:
https://bugzilla.redhat.com/attachment.cgi?id=741896

and here's the relevant BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=956988

On Wed, 2013-05-01 at 15:55 +0100, Mircea Markus wrote:
 Hi Martin,
 
 Paul mentioned a severe degradation in performance between 5.1 and 5.2 for 
 replicated + embedded + transactional + pessimistic caches, for write-heavy 
 access. Do we have any tests we can run to check this? 
 
 Cheers,


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] write-heavy performance degradation between 5.1 and 5.2

[Paul Ferraro]

Damn you, bugzilla!!!
Attached.

On Wed, 2013-05-01 at 11:05 -0400, Paul Ferraro wrote:
 FYI - here's a summary of EAP 6.0 vs 6.1 performance:
 https://bugzilla.redhat.com/attachment.cgi?id=741896
 
 and here's the relevant BZ:
 https://bugzilla.redhat.com/show_bug.cgi?id=956988
 
 On Wed, 2013-05-01 at 15:55 +0100, Mircea Markus wrote:
  Hi Martin,
  
  Paul mentioned a severe degradation in performance between 5.1 and 5.2 for 
  replicated + embedded + transactional + pessimistic caches, for write-heavy 
  access. Do we have any tests we can run to check this? 
  
  Cheers,
 
 



cluster_performance_report.ods
Description: application/vnd.oasis.opendocument.spreadsheet
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] infinispan-dev Digest, Vol 40, Issue 19

[Paul Ferraro]

I haven't looked into this yet - still focused on EAP 6.0.1 issues.
I'll create a branch for the 5.2 upgrade today.

On Wed, 2012-07-25 at 13:42 +0200, Ales Justin wrote:
 Paul / Richard, any update?
 
 As I need this in, in order to finally release first version of CapeDwarf.
 
 -Ales
 
  Paul/Richard should be integrating it soon.
  
  On Jul 23, 2012, at 11:18 PM, Ales Justin wrote:
  
  This was released last Friday but due to some glitches, I was only about 
  to get around to blogging about it now: http://goo.gl/lX4Tq
  
  Thanks to everyone in their involvement, particularly Vladimir and Adrian 
  :)
  
  Any plans to get this into AS7.2.0.Alpha1?
 
 
 


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] removing Cache::with(CL)

[Paul Ferraro]

On Fri, 2012-05-11 at 10:24 +0200, Ales Justin wrote:
  The details of the query module are a little out of my realm of
  experience.  I'm CC'ing infinispan-dev, to open up the larger discussion
  to classloading and compatibility with modular environments.
  
  Off the top of my head, it seems like you need a custom
  KeyTransformationHandler that can resolve classes using a ModuleLoader
  (i.e. module ID + class name).  Thoughts?
 
 That's one way of solving it.
 
 But AdvancedCache::with(CL) already solves this problem - that's why I used 
 it (I remembered later :-)).

But that only helps during serialization - not deserialization where
this classloader is no longer available, thus class resolution will
fail.

 Where I think the two: AC::with(CL) and ServiceModuleLoader impl of 
 ClassResolver, should no be connected.
 Since they solve diff problems, imo.

True, but with(CL) can really only be used (e.g. in a cluster, with a
cache store, etc.) if storeAsBinary is enabled - for the reason
mentioned above.

 Anyway, I'm now gonna try and hunt down where plain ML impl of CR somes in ...
 
 -Ales
 
  On Thu, 2012-05-10 at 23:10 +0200, Ales Justin wrote:
  If I do subject I get this CNFE, see below.
  
  Looks like I still need a combination of Cache::with(CL) -- so this code 
  sees Key class,
  and at the same time I don't want Infinispan to depend on GAE API.
  Where I also need to have SML as ClassResolver.
  
  Are you sure setting CL on Cache breaks ClassResolver?
  
  -Ales
  
  ---
  
  23:00:50,321 ERROR [org.infinispan.query.backend.KeyTransformationHandler] 
  (http-/192.168.1.101:8080-2) ISPN014001: Could not locate key class 
  com.google.appengine.api.datastore.Key: java.lang.ClassNotFoundException: 
  com.google.appengine.api.datastore.Key
 at java.net.URLClassLoader$1.run(URLClassLoader.java:202) 
  [classes.jar:1.6.0_31]
 at java.security.AccessController.doPrivileged(Native Method) 
  [classes.jar:1.6.0_31]
 at java.net.URLClassLoader.findClass(URLClassLoader.java:190) 
  [classes.jar:1.6.0_31]
 at java.lang.ClassLoader.loadClass(ClassLoader.java:306) 
  [classes.jar:1.6.0_31]
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) 
  [classes.jar:1.6.0_31]
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247) 
  [classes.jar:1.6.0_31]
 at java.lang.Class.forName0(Native Method) [classes.jar:1.6.0_31]
 at java.lang.Class.forName(Class.java:247) [classes.jar:1.6.0_31]
 at org.infinispan.util.Util.loadClassStrict(Util.java:127) 
  [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
 at 
  org.infinispan.query.backend.KeyTransformationHandler.getCustomTransformer(KeyTransformationHandler.java:108)
 at 
  org.infinispan.query.backend.KeyTransformationHandler.stringToKey(KeyTransformationHandler.java:96)
 at 
  org.infinispan.query.impl.CacheQueryImpl.fromEntityInfosToKeys(CacheQueryImpl.java:174)
 at 
  org.infinispan.query.impl.CacheQueryImpl.iterator(CacheQueryImpl.java:144)
 at 
  org.infinispan.query.impl.CacheQueryImpl.iterator(CacheQueryImpl.java:137)
 at 
  org.jboss.capedwarf.datastore.query.PreparedQueryImpl.createQueryIterator(PreparedQueryImpl.java:108)
   [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
 at 
  org.jboss.capedwarf.datastore.query.PreparedQueryImpl.asQueryResultIterator(PreparedQueryImpl.java:73)
   [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
 at 
  org.jboss.capedwarf.datastore.query.PreparedQueryImpl.asIterator(PreparedQueryImpl.java:64)
   [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
 at 
  org.jboss.capedwarf.datastore.query.PreparedQueryImpl.asIterator(PreparedQueryImpl.java:60)
   [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
 at 
  org.jboss.test.capedwarf.datastore.test.PreparedQueryTestCase.testAsIteratorWithOptionstestCountEntities(PreparedQueryTestCase.java:77)
   [classes:]
  
  
  
 


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] removing Cache::with(CL)

[Paul Ferraro]

The details of the query module are a little out of my realm of
experience.  I'm CC'ing infinispan-dev, to open up the larger discussion
to classloading and compatibility with modular environments.

Off the top of my head, it seems like you need a custom
KeyTransformationHandler that can resolve classes using a ModuleLoader
(i.e. module ID + class name).  Thoughts?

Paul

On Thu, 2012-05-10 at 23:10 +0200, Ales Justin wrote:
 If I do subject I get this CNFE, see below.
 
 Looks like I still need a combination of Cache::with(CL) -- so this code sees 
 Key class,
 and at the same time I don't want Infinispan to depend on GAE API.
 Where I also need to have SML as ClassResolver.
 
 Are you sure setting CL on Cache breaks ClassResolver?
 
 -Ales
 
 ---
 
 23:00:50,321 ERROR [org.infinispan.query.backend.KeyTransformationHandler] 
 (http-/192.168.1.101:8080-2) ISPN014001: Could not locate key class 
 com.google.appengine.api.datastore.Key: java.lang.ClassNotFoundException: 
 com.google.appengine.api.datastore.Key
   at java.net.URLClassLoader$1.run(URLClassLoader.java:202) 
 [classes.jar:1.6.0_31]
   at java.security.AccessController.doPrivileged(Native Method) 
 [classes.jar:1.6.0_31]
   at java.net.URLClassLoader.findClass(URLClassLoader.java:190) 
 [classes.jar:1.6.0_31]
   at java.lang.ClassLoader.loadClass(ClassLoader.java:306) 
 [classes.jar:1.6.0_31]
   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) 
 [classes.jar:1.6.0_31]
   at java.lang.ClassLoader.loadClass(ClassLoader.java:247) 
 [classes.jar:1.6.0_31]
   at java.lang.Class.forName0(Native Method) [classes.jar:1.6.0_31]
   at java.lang.Class.forName(Class.java:247) [classes.jar:1.6.0_31]
   at org.infinispan.util.Util.loadClassStrict(Util.java:127) 
 [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
   at 
 org.infinispan.query.backend.KeyTransformationHandler.getCustomTransformer(KeyTransformationHandler.java:108)
   at 
 org.infinispan.query.backend.KeyTransformationHandler.stringToKey(KeyTransformationHandler.java:96)
   at 
 org.infinispan.query.impl.CacheQueryImpl.fromEntityInfosToKeys(CacheQueryImpl.java:174)
   at 
 org.infinispan.query.impl.CacheQueryImpl.iterator(CacheQueryImpl.java:144)
   at 
 org.infinispan.query.impl.CacheQueryImpl.iterator(CacheQueryImpl.java:137)
   at 
 org.jboss.capedwarf.datastore.query.PreparedQueryImpl.createQueryIterator(PreparedQueryImpl.java:108)
  [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
   at 
 org.jboss.capedwarf.datastore.query.PreparedQueryImpl.asQueryResultIterator(PreparedQueryImpl.java:73)
  [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
   at 
 org.jboss.capedwarf.datastore.query.PreparedQueryImpl.asIterator(PreparedQueryImpl.java:64)
  [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
   at 
 org.jboss.capedwarf.datastore.query.PreparedQueryImpl.asIterator(PreparedQueryImpl.java:60)
  [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
   at 
 org.jboss.test.capedwarf.datastore.test.PreparedQueryTestCase.testAsIteratorWithOptionstestCountEntities(PreparedQueryTestCase.java:77)
  [classes:]
 


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Why Externalizer does not need to extend java.io.Serializable

[Paul Ferraro]

Thanks for the clarification Galder.  I'm in the process of creating 
Externalizers to optimize the serialization done by Infinispan and this 
clears up a lot of my confusion.

It's ok by me if you make this change in 5.1.x.

On 05/03/2012 02:23 AM, Galder Zamarreño wrote:
 Re: https://issues.jboss.org/browse/ISPN-2029

 Just a heads up as a result of an interesting discussion with Paul Ferraro 
 last night:

 So far Externalizer interface has extended Serializable and last night I was 
 trying to wonder why that was.

 As you guys might remember (https://docs.jboss.org/author/x/PwY5), there's 
 two type of externalizers: user friendly and advanced.

 The user friendly ones do not require any pre-registration or anything and 
 thanks to the ability of JBMAR to ship Externalizers to remote nodes, we can 
 support such use case. However, this requires Externalizer impls to be 
 Serializable or Externalizable somehow.

 However, that requirement is not there for advanced externalizers cos these 
 must be registered somehow, either via programmatic or XML configuration, so 
 in these case there's no shipping of Externalizer impls at all.

 So, I'm gonna remove 'implements Serializable' from 
 org.infinispan.marshall.Externalizer and instead require that any 
 user-friendly externalizers are marker as Serializable or similar.

 I'll be making this change in master, but what about 5.1.x? This change is 
 not urgent but clarifies what the externalizer serialization requirements are.

 Cheers,
 --
 Galder Zamarreño
 Sr. Software Engineer
 Infinispan, JBoss Cache


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache

[Paul Ferraro]

- Original Message -
 From: Galder Zamarreño gal...@redhat.com
 To: Paul Ferraro paul.ferr...@redhat.com
 Cc: Jason T. Greene jason.gre...@redhat.com, Bela Ban 
 b...@redhat.com, infinispan -Dev List
 infinispan-dev@lists.jboss.org, hibernate-...@lists.jboss.org, 
 jboss-as7-...@lists.jboss.org Development
 jboss-as7-...@lists.jboss.org, David M. Lloyd david.ll...@redhat.com
 Sent: Tuesday, March 6, 2012 2:02:44 PM
 Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for 
 clustered JPA second level cache
 
 
 On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
 
  - Original Message -
  From: Jason T. Greene jason.gre...@redhat.com
  To: David M. Lloyd david.ll...@redhat.com
  Cc: Galder Zamarreño gal...@redhat.com, Paul Ferraro
  pferr...@redhat.com, Bela Ban b...@redhat.com,
  infinispan -Dev List infinispan-dev@lists.jboss.org,
  hibernate-...@lists.jboss.org,
  jboss-as7-...@lists.jboss.org Development
  jboss-as7-...@lists.jboss.org
  Sent: Tuesday, March 6, 2012 10:30:11 AM
  Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan
  dependency for clustered JPA second level cache
  
  On 3/6/12 9:28 AM, David M. Lloyd wrote:
  On 03/06/2012 09:21 AM, Galder Zamarreño wrote:
  This reminds me that we had a discussion about this a few months
  back: http://goo.gl/DJLhB
  
  At the time, it wasn't clear whether you can use
  ModularClassResolver in a non-module env. Seems like it's not
  possible.
  
  So, one option is to have a class resolver lookup class, or
  similar so that AS7 can pass us the right ClassResolver.
  
  There might a quicker option here though:
  - Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and
  provide
  a variant of JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan
  (this requires JBossMarshaller to be made non-final)
  - Override JBossMarshaller.inject(), call super.inject() and
  then
  call baseCfg.setClassResolver(…)
  - This would require that the VersionAwareMarshaller extension
  be
  passed the ModuleLoader that ModularClassResolver requires.
  - Configure Infinispan with this new marshaller, via
  SerializationConfiguration. Thankfully you can now pass an
  instance of the marshaller to it, so no need to do any magic
  ModuleLoader lookup from the VersionAwareMarshaller extension.
  
  Scott, other than the change in JBossMarshaller to be made
  non-final, the rest can built on AS7. Wanna have a go? Ping me
  on
  IRC if you need help.
  
  Cheers,
  
  p.s. Silly question, how come this issue is not present in HTTP
  session replication use case or EJB3 SFSB?
  
  It actually is present anywhere we're using Infinispan (I think).
  It
  just hasn't blown up yet anywhere public (in this case it's a 90%
  effective solution versus a 100% effective solution).
  
  Session replication does setup a custom marshaller, so it does in
  fact
  work. I think the issue is just that the hibernate-infinispan,
  which
  is
  part of the hibernate project set, and not AS code does not do
  this,
  and
  it doesn't expose a way to do it.
  
  Sort of...
  
  To summarize:
  The fundamental issue is that Infinispan uses the same marshaller
  instance for all caches within a cache manager - which doesn't map
  cleanly to our use case, which uses a cache instance per
  application - thus requires cache-grained marshalling
  configuration.
 
 Well, this is not exactly correct since 5.0. Internally, we
 differentiate between a global marshaller and a per-cache
 marshaller. What's the difference? The classloader with which
 they're configured.

Yes - but there's a difference between supplying a classloader per cache and 
providing a custom marshaller per cache.

 Since 5.0, you can configure the classloader to use per cache. You
 can even configure the classloader per invocation with
 cache.with(cl)….

And we use both of these.  The ClassLoader supplied to the CacheConfiguration 
is used to resolve configuration classes (e.g. cache stores).  The AS7 2LC 
region factory implementations (which extend hibernate-infinispan) currently 
use the ClassLoader per invocation to resolve entity/PK objects - but this is 
too restrictive, since the Infinispan's marshaller needs to know about more 
classes than are available to the application class loader (hence this 
discussion), and even that is still not without issues (e.g. ISPN-1220).

 If that's not helping you, we were wasting our time when we did
 this...

I disagree.  Allowing a user to supply a classloader to a cache/invocation is 
incredibly useful.

  To work around this, we typically store MarshalledValues in the
  cache - which are marshalled/unmarshalled using a marshalling
  configuration specific to the application (e.g. via a
  ModularClassResolver using the ModuleLoader of the deployment
  unit).
  https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/MarshalledValue.java
  https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java

Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache

[Paul Ferraro]

- Original Message -
 From: Scott Marlow smar...@redhat.com
 To: infinispan -Dev List infinispan-dev@lists.jboss.org
 Cc: hibernate-...@lists.jboss.org, jboss-as7-...@lists.jboss.org 
 Development jboss-as7-...@lists.jboss.org,
 Galder Zamarreño gal...@redhat.com
 Sent: Tuesday, March 6, 2012 2:45:03 PM
 Subject: Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan 
 dependency for clustered JPA second level
 cache
 
 On 03/06/2012 02:27 PM, Galder Zamarreño wrote:
  So, to summarise all of this. What I suggest is this:
 
  - Short term:
  The quick fix I suggest in
  http://lists.jboss.org/pipermail/infinispan-dev/2012-March/010317.html
 
 Do we want to try this (requires a new build of Infinispan I think)?
  Or
 should applications workaround the issue until we can reach the
 medium/long term?
 
 
  - Medium term:
  Have a way to pass in marshalling configurations per cache manager
  and per-cache (or an abstraction of it), which allows the right
  class resolver to be passed in. (***)
  https://issues.jboss.org/browse/ISPN-1367
 
 ISPN-1367 is targeted to Infinispan 5.2, any idea of the target
 release
 date for that?  I'm curious as to which AS release it might align
 with.
 
 
  - Long term:
  https://issues.jboss.org/browse/ISPN-1413
 
  (***) I still don't fully understand how web apps don't have the
  same issue as 2LC of not seeing Infinispan classes (Reminder:
  we're not talking about the contents of the cache, but about the
  Infinispan classes themselves).
 
 https://github.com/jbossas/jboss-as/blob/master/web/src/main/java/org/jboss/as/web/deployment/JBossContextConfig.java
 appears to be wired to use Paul's ClassLoaderAwareClassResolver.

ClassLoaderAwareClassResolver is just a hack to workaround AS7-2496 (i.e. Weld 
still does TCCL switching).
The bottom line is, we still rely on ModularClassResolver to marshal/unmarshal 
session objects.

 
  On Mar 6, 2012, at 8:19 PM, Galder Zamarreño wrote:
 
 
  On Mar 6, 2012, at 8:06 PM, David M. Lloyd wrote:
 
  On 03/06/2012 01:02 PM, Galder Zamarreño wrote:
  On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
  /snip
  To work around this, we typically store MarshalledValues in the
  cache - which are marshalled/unmarshalled using a marshalling
  configuration specific to the application (e.g. via a
  ModularClassResolver using the ModuleLoader of the deployment
  unit).
  https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/MarshalledValue.java
  https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/SimpleMarshalledValue.java
  https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/HashableMarshalledValue.java
 
  Isn't a class resolver and a class loader, functionality wise,
  doing the same thing? I wonder if a custom classloader could
  not be built that delegates to a ModularClassResolver...
 
  No, not really.  A class loader loads a class, given a name.  But
  a
  class resolver loads a class given a name *and* stream
  information.  The
  modular class resolver reads the stream information to know which
  class
  loader houses the class in question.  This is critically
  important
  because it's possible (common even) for more than one class to
  exist in
  an AS instance with the same name.  And there is no single class
  loader
  which has visibility to all classes which could potentially be
  stored in
  a cache.
 
  Yes, accepting a class loader to use is a powerful feature.
   However it
  *should* just be a convenience abstraction over a more
  fundamental
  feature which allows a class resolver to be set.
 
  Thanks for the clarification, makes sense.
 
  So, if I understand this correctly, Infinispan should really be
  enhanced to accept global and per-cache class resolvers, or more
  globally, as paul suggested below, marshalling configuration
  instances (or abstractions of them).
 
  I think https://issues.jboss.org/browse/ISPN-1367 should be
  reporpoused to do this.
 
 
  So, essentially Infinispan itself only ever has to
  marshal/unmarshal a byte[] wrapper - so the AS has full
  control over the marshalling process.
 
  I would recommend that the 2LC do something similar, and
  include a mechanism for providing a MarshallingConfiguration
  per persistence unit.
 
  Possibly…
 
  --
  Galder Zamarreño
  Sr. Software Engineer
  Infinispan, JBoss Cache
 
 
 
  --
  - DML
  ___
  infinispan-dev mailing list
  infinispan-dev@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@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/infinispan-dev
 
  --
  Galder Zamarreño
  Sr. Software Engineer
  Infinispan, JBoss Cache

Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache

[Paul Ferraro]

- Original Message -
 From: David M. Lloyd david.ll...@redhat.com
 To: infinispan -Dev List infinispan-dev@lists.jboss.org
 Cc: hibernate-...@lists.jboss.org, jboss-as7-...@lists.jboss.org 
 Development jboss-as7-...@lists.jboss.org,
 Galder Zamarreño gal...@redhat.com
 Sent: Tuesday, March 6, 2012 2:55:18 PM
 Subject: Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan 
 dependency for clustered JPA second level
 cache
 
 On 03/06/2012 01:27 PM, Galder Zamarreño wrote:
  (***) I still don't fully understand how web apps don't have the
  same issue as 2LC of not seeing Infinispan classes (Reminder:
  we're not talking about the contents of the cache, but about the
  Infinispan classes themselves).
 
 It's possible that someone saw the exception and said to themselves,
 oh... well I'll just add Infinispan to all web apps, and then the
 patch slipped by the code review process.  Other problems will
 continue
 to lurk beneath the surface though.

No - web applications don't have this problem because web session clustering 
uses ModularClassResolver during marshalling/unmarshalling of sessions.

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Removing Infinispan dependency on the Hibernate-Infinispan module in 4.x

[Paul Ferraro]

On Thu, 2012-02-09 at 15:52 +, Sanne Grinovero wrote:
 On 9 February 2012 15:37, Bela Ban b...@redhat.com wrote:
 
 
  On 2/9/12 3:24 PM, Sanne Grinovero wrote:
  On 9 February 2012 14:09, Bela Banb...@redhat.com  wrote:
 
 
  On 2/9/12 3:01 PM, Dan Berindei wrote:
  On Thu, Feb 9, 2012 at 2:45 PM, Manik Surtanima...@jboss.org  Â 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.

No - there's only 1.  AS7 just adds an JChannel extension that uses a
MuxUpHandler by default, and overrides the setUpHandler(...) method to
set ths MuxUpHandler's default handler rather than overriding the up
handler altogether (this is needed so that Infinispan's rpc dispatcher
doesn't mess with our existing up handler).  AS6 used to have some
customization to handle muxing of state transfer - but that doesn't
exist in AS7.

 Sanne
 
 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] looking again at AS7-3290 and Hibernate 4.0.1...

[Paul Ferraro]

On Wed, 2012-02-08 at 14:14 +0100, Galder Zamarreño wrote:
 On Feb 8, 2012, at 11:27 AM, Sanne Grinovero wrote:
 
  On 8 February 2012 04:14, Scott Marlow smar...@redhat.com wrote:
  On 02/07/2012 10:25 AM, Sanne Grinovero wrote:
  
  On 7 February 2012 15:21, Scott Marlowsmar...@redhat.com  wrote:
  
  On 02/07/2012 10:07 AM, Sanne Grinovero wrote:
  
   I'm not that worried about OGM (unless someone wants double buffering
   ;), its more about users wanting to package in different versions in
   Hibernate (newer/older).
  
  Even if someone wanted double buffering, OGM was already upgraded to
  use Hibernate 4, so this doesn't apply.
  
  
  
  I think it depends on whether OGM will always work with the Hibernate
  4.x version that is used in AS 7.x.  If OGM moves forward (Hibernate
  version wise) and starts requiring a different version than the one that
  is static wired into the Infinispan module, the user might want multiple
  Hibernate 4.x versions to be wired into the Infinispan module.  I'm not
  sure but if Infinispan has multiple versions of Hibernate in its
  classpath, that probably would interfere with the custom commands (I
  would think).
  
  
  Good point. It's unlikely for OGM to need a 2nd level cache, but this
  reasoning applies to Hibernate Search as well, for which we often
  depend on a newer version of Core than what is provided by the AS.
  
  
  How hard would it be to allow a different way of passing the custom 
  commands
  in?  Would this be a short term change in the next few weeks or longer 
  term?
  
  Sorry I'm not sure I understood what you are proposing. How do you
  suggest it should work?
 
 Hmmm, I don't see an easy/quick way to fix this. So far, these are the 
 options that could be implemented in Infinispan:
 
 1. Separate between cache-level and global module command extensions. By 
 doing that, Hibernate 2LC can implement a cache command factory and that 
 would get resolved (via service loader) when the cache is created, which 
 happens when application is deployed. This avoids AS7 Infinispan subsystem 
 being tied to Hibernate.
 
 2. Alternatively something suggested by Sanne is plugging the command 
 factories (and initializer) via an SPI (i.e. addModuleCommandExtensions or 
 similar), so that loading happens in Hibernate and it passes it into the 
 created cache (similar to listeners). A problem with this is unless this is 
 passed when the cache is started, there could be a small window when the 
 cache receives a command for which no factory to resolve it is available cos 
 addModuleCommandExtensions has not been called yet.
 
 I also see an option for those in charge of managed environments:
 
 3. A third solution here is for AS7, or any other managed env, to associate a 
 cache manager with each deployment and associate pass the right classloader 
 in. That way, the cache manager is created when deployment comes in and we 
 can pass in the right Hibernate and Infinispan CLs. As said by Paul, this 
 would require work on the AS7, but conceptually, this is in line with what we 
 want to do with https://issues.jboss.org/browse/ISPN-1413 long term…

Require a separate channel for every deployment?  I don't think that's
the way to go exactly.  Rather, I think a better solution is to
associate a cache manager with a module - where the module can supply
the global configuration with its class loader.  Individual caches would
be associated with a deployment created by this module.

I've opened AS7-3655 to make this possible.

Paul

 I personally favour this 3rd option
 
  --Sanne
  
  ___
  infinispan-dev mailing list
  infinispan-dev@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@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] The need for a 5.1.1

[Paul Ferraro]

On Thu, 2012-01-26 at 22:42 +, Manik Surtani wrote:
 I really didn't want to do this, but it looks like a 5.1.1 will be
 necessary.  The biggest (critical, IMO, for 5.1.1) issues I see are:
 
 
 1. https://issues.jboss.org/browse/ISPN-1786 - I presume this has to
 do with a bug Mircea spotted that virtual nodes were not being enabled
 by the config parser.  Which meant that even in the case of tests
 enabling virtual nodes, we still saw uneven distribution and hence
 poor performance (well spotted, Mircea).  
 2. Related to 1, I don't think there is a JIRA for this yet, to change
 the default number of virtual nodes from 1 to 100 or so.  After we
 profile and analyse the impact of enabling this by default.  I'm
 particularly concerned about (a) memory footprint and (b) effects on
 Hot Rod relaying topology information back to clients.  Maybe 10 is a
 more sane default as a result.
 3. https://issues.jboss.org/browse/ISPN-1788 - config parser out of
 sync with XSD!
 4. https://issues.jboss.org/browse/ISPN-1798 - forceReturnValues
 parameter in the RemoteCacheManager.getCache() method is ignored!
 
 
 In addition, we may as well have these nice to have's in as well:
 
 
 https://issues.jboss.org/browse/ISPN-1787
 https://issues.jboss.org/browse/ISPN-1793
 https://issues.jboss.org/browse/ISPN-1795
 https://issues.jboss.org/browse/ISPN-1789
 https://issues.jboss.org/browse/ISPN-1784
 
 
 What do you think?  Anything else you feel that is crucial for a
 5.1.1?  I'd like to do this sooner rather than later, so we can still
 focus on 5.2.0.  So please respond asap.
 
 
 Paul, I'd also like your thoughts on this from an AS7 perspective.

It would be nice to see those few minor issues that I raised post-FINAL,
specifically the xsd update and removing some of those startup WARNings.

I'm also chasing down a issue that we're seeing occasionally on our test
runs where we're attempting to perform a cache operation from a
@ViewChanged event which occasionally causes a flurry of Failed to
prepare view CacheView due to a
org.infinispan.remoting.transport.jgroups.SuspectException.  This is
definitely something that we need to figure out ASAP.  I'm not sure yet
if this is an Infinispan problem or whether I'm trying to do something
stupid.  I've opened ISPN-1806 just in case.

Paul

 Cheers
 Manik
 
 --
 Manik Surtani
 ma...@jboss.org
 twitter.com/maniksurtani
 
 
 Lead, Infinispan
 http://www.infinispan.org
 
 
 
 
 
 
 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Infinispan 5.1 + AS 7.1

[Paul Ferraro]

Hey Dan,

Any progress on this?  I'd like to push the Infinispan/JGroups upgrade
this week if possible, but this is currently blocking my progress.
Thanks,

Paul

On Fri, 2011-10-14 at 15:36 +0300, Dan Berindei wrote:
 Hi Paul
 
 Yeah, I have changed replicated mode's state transfer to transfer
 state in parallel from all the existing nodes and I'm using a
 consistent hash to determine which keys should be pushed by each node.
 This one looks tricky, the transport reports 0 members but it should
 always have at least the current node as a member.
 
 I'll try to run with REPL_ASYNC to see if it changes anything, but I
 don't think it should.
 
 Cheers
 Dan
 
 
 On Fri, Oct 14, 2011 at 1:27 AM, Paul Ferraro paul.ferr...@redhat.com wrote:
  Hey all,
 
  I'm a bit stuck with the Infinispan 5.1 upgrade in AS 7.1.
  I've tried both with BETA1 and a SNAPSHOT build from today.
 
  When a deployment forces a cache to start, I see the following
  stacktrace:
 
  14:06:07,584 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) 
  MSC1: Failed to start service jboss.infinispan.web.repl: 
  org.jboss.msc.service.StartException in service jboss.infinispan.web.repl: 
  Failed to start service
 at 
  org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1780)
   [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
 at 
  java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   [:1.6.0_23]
 at 
  java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   [:1.6.0_23]
 at java.lang.Thread.run(Thread.java:679) [:1.6.0_23]
  Caused by: org.infinispan.CacheException: Unable to invoke method private 
  void org.infinispan.statetransfer.BaseStateTransferManagerImpl.start() 
  throws java.lang.Exception on object
 at 
  org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
 at 
  org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:825)
 at 
  org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:624)
 at 
  org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:527)
 at 
  org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:177)
 at org.infinispan.CacheImpl.start(CacheImpl.java:462)
 at 
  org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:574)
 at 
  org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:453)
 at 
  org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:467)
 at 
  org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
 at 
  org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
 at 
  org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
 at 
  org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824)
   [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
 at 
  org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759)
   [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
 ... 3 more
  Caused by: java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
  [:1.6.0_23]
 at 
  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   [:1.6.0_23]
 at 
  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [:1.6.0_23]
 at java.lang.reflect.Method.invoke(Method.java:616) [:1.6.0_23]
 at 
  org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
 ... 16 more
  Caused by: java.lang.IllegalArgumentException: Invalid cache list for 
  consistent hash: []
 at 
  org.infinispan.distribution.ch.AbstractWheelConsistentHash.setCaches(AbstractWheelConsistentHash.java:96)
 at 
  org.infinispan.distribution.ch.ConsistentHashHelper.createConsistentHash(ConsistentHashHelper.java:122)
 at 
  org.infinispan.statetransfer.ReplicatedStateTransferManagerImpl.createConsistentHash(ReplicatedStateTransferManagerImpl.java:56)
 at 
  org.infinispan.statetransfer.BaseStateTransferManagerImpl.start(BaseStateTransferManagerImpl.java:143)
 
  What's particularly puzzling is that this is a REPL_ASYNC cache with
  state transfer enabled.  Why are we attempting to create a consistent
  hash here?  Dan, is this related to your work?
 
  Thanks in advance,
 
  Paul
 
  ___
  infinispan-dev mailing list
  infinispan-dev@lists.jboss.org
  https://lists.jboss.org/mailman/listinfo/infinispan-dev
 
 
 ___
 infinispan-dev

[infinispan-dev] Infinispan 5.1 + AS 7.1

[Paul Ferraro]

Hey all,

I'm a bit stuck with the Infinispan 5.1 upgrade in AS 7.1.
I've tried both with BETA1 and a SNAPSHOT build from today.

When a deployment forces a cache to start, I see the following
stacktrace:

14:06:07,584 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) 
MSC1: Failed to start service jboss.infinispan.web.repl: 
org.jboss.msc.service.StartException in service jboss.infinispan.web.repl: 
Failed to start service
at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1780)
 [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
[:1.6.0_23]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
[:1.6.0_23]
at java.lang.Thread.run(Thread.java:679) [:1.6.0_23]
Caused by: org.infinispan.CacheException: Unable to invoke method private void 
org.infinispan.statetransfer.BaseStateTransferManagerImpl.start() throws 
java.lang.Exception on object 
at 
org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
at 
org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:825)
at 
org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:624)
at 
org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:527)
at 
org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:177)
at org.infinispan.CacheImpl.start(CacheImpl.java:462)
at 
org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:574)
at 
org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:453)
at 
org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:467)
at 
org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
at 
org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
at 
org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824)
 [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759)
 [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
... 3 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
[:1.6.0_23]
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
[:1.6.0_23]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 [:1.6.0_23]
at java.lang.reflect.Method.invoke(Method.java:616) [:1.6.0_23]
at 
org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
... 16 more
Caused by: java.lang.IllegalArgumentException: Invalid cache list for 
consistent hash: []
at 
org.infinispan.distribution.ch.AbstractWheelConsistentHash.setCaches(AbstractWheelConsistentHash.java:96)
at 
org.infinispan.distribution.ch.ConsistentHashHelper.createConsistentHash(ConsistentHashHelper.java:122)
at 
org.infinispan.statetransfer.ReplicatedStateTransferManagerImpl.createConsistentHash(ReplicatedStateTransferManagerImpl.java:56)
at 
org.infinispan.statetransfer.BaseStateTransferManagerImpl.start(BaseStateTransferManagerImpl.java:143)

What's particularly puzzling is that this is a REPL_ASYNC cache with
state transfer enabled.  Why are we attempting to create a consistent
hash here?  Dan, is this related to your work?

Thanks in advance,

Paul

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Request for feedback on cache store support in AS7 Infinispan subsystem

[Paul Ferraro]

- Original Message -
 From: Galder Zamarreño gal...@redhat.com
 To: infinispan -Dev List infinispan-dev@lists.jboss.org
 Sent: Friday, September 16, 2011 3:49:32 AM
 Subject: Re: [infinispan-dev] Request for feedback on cache store support in 
 AS7 Infinispan subsystem
 On Sep 15, 2011, at 5:34 PM, Paul Ferraro wrote:
 
  /snip
 
  The amended Infinispan subsystem schema can be found here:
  https://github.com/pferraro/jboss-as/blob/master/build/src/main/resources/docs/schema/jboss-as-infinispan_1_0.xsd
 
 Hmmm, is the xsd meant to show the new changes? I only see custom and
 file store in there

Oops - wrong branch:
Here's the correct link to the updated xsd:
https://github.com/pferraro/jboss-as/blob/infinispan/build/src/main/resources/docs/schema/jboss-as-infinispan_1_0.xsd

  For the jdbc cache stores, which come in 3 flavors, I've
  consolidated
  them into a single configuration element jdbc-store/, where the
  variant is implied the defined tables. After providing default
  values
  for all the required fields, we arrive at the following minimal
  configuration:
  e.g.
  jdbc-store datasource=java:jboss/jdbc/somedatabase/
 
  I started with the assumption that the database resource will always
  come from an AS-managed DataSource.
 
  To use a string-based jdbc store, we specify the type of table to
  use:
  e.g.
 
  jdbc-store datasource=java:jboss/jdbc/somedatabase
   entry-table/
  /jdbc-store
 
  Likewise, if we want to use a binary jdbc store:
  e.g.
  jdbc-store datasource=java:jboss/jdbc/somedatabase
   bucket-table/
  /jdbc-store
 
  Using both entry-table/ and bucket-table/ (or neither) indicates
  the
  use of a mixed jdbc store.
 
  The tables themselves are fully customizable (shown with their
  default
  values):
  e.g.
  jdbc-store datasource=java:jboss/jdbc/somedatabase
  bucket-table prefix=ispn_bucket batch-size=100
  fetch-size=100
   id-column name=id type=VARCHAR/
   data-column name=datum type=BINARY/
   timestamp-column name=version type=BIGINT/
  /bucket-table
  entry-table prefix=ispn_entry batch-size=100 fetch-size=100
   id-column name=id type=VARCHAR/
   data-column name=datum type=BINARY/
   timestamp-column name=version type=BIGINT/
  /entry-table
  /jdbc-store
 
 Sounds good.
 
  The schema for the remote cache store is far simpler. You can
  specify a
  specific remote cache name, server list, and hot rod client
  properties
  are directly enumerated:
  e.g.
  remote-store cache=some-named-cache servers=127.0.0.1:11311
   property
   name=infinispan.client.hotrod.request_balancing_strategy.../property
  /remote-store
 
  If the cache attribute is omitted, we assume the default cache is to
  be
  used.
 
  Unfortunately, there doesn't seem to be a way to integrate the
  thread
  pools used by RemoteCache/RemoteCacheManager with the AS7 threading
  subsystem. In order to do this, RemoteCacheStoreConfig would need
  methods for providing ExecutorFactory implementations, similar to
  the
  way GlobalConfiguration works.
 
 Hmmm, mind creating a JIRA on this? The HotRod client should be play
 nicely to allow executor factories to be injected.

https://issues.jboss.org/browse/ISPN-1389

 
  I haven't started on the cloud-based store yet, as it's kind of a
  dependency nightmare.
 
 I know, jclouds' dependency list is huge :(
 
 If Adrian is listening, any chance of somehow reducing it? Otherwise,
 I think he should be in JUDCon (if not in JavaOne earlier), so I'll
 try to grab him there :)
 
 
  Thoughts?
 
  Paul
 
  ___
  infinispan-dev mailing list
  infinispan-dev@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@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Request for feedback on cache store support in AS7 Infinispan subsystem

[Paul Ferraro]

- Original Message -
 From: Tristan Tarrant ttarr...@redhat.com
 To: infinispan-dev@lists.jboss.org
 Sent: Friday, September 16, 2011 4:07:23 AM
 Subject: Re: [infinispan-dev] Request for feedback on cache store support in 
 AS7 Infinispan subsystem
 On 09/16/2011 09:56 AM, Sanne Grinovero wrote:
  On 16 September 2011 09:50, Tristan Tarrantttarr...@redhat.com
  wrote:
 
  I was thinking if there could be a better/simpler way and allow
  users to
  deploy key2stringmappers in the same way that jdbc drivers are
  deployed:
  by placing a jar with an appropriate
  META-INF/services/org.infinispan.loaders.keymappers.Key2StringMapper
  in
  the deployments dir.
 
  What do you think ?
  I'd love that. The problem is that the Key2StringMapper
  implementations would need to depend on the key types they where
  designed for.
 
 That would be a problem when deploying via the module method too,
 wouldn't it ? You'd have to decouple the classes that make up your key
 out of your application...

The other complication this introduces is that the Infinispan API would have to 
be exposed by default, i.e. available to the application classloader the same 
way javax.sql, and all spec apis are.
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

[infinispan-dev] Request for feedback on cache store support in AS7 Infinispan subsystem

[Paul Ferraro]

Hi all,

In AS 7.0, only the those cache store implementations packaged in
infinispan-core were usable by default.  While the Infinispan subsystem
schema allowed users to use any cache store implementation (via store
class=.../), they need to manually add the relevant jars to the
org.infinispan module, and update the module.xml file accordingly so
that the subsystem's module classloader is aware of these cache store
classes.

To simplify the use of other common cache store implementations, I'm in
the process of working on the following jira, which aims to include the
jdbc, remote, and cloud cache store jars in the org.infinispan module by
default:
https://issues.jboss.org/browse/AS7-1713

As well as including the relevant jars, we would also like to simplify
their definition (like we did for file-store/, such that users don't
need to specify class names, provide as many sensible defaults as
possible, and take care of any required service dependencies.

I've created a draft of what I thought could be workable schema for the
remote and jdbc cache stores and would like some feedback.

The amended Infinispan subsystem schema can be found here:
https://github.com/pferraro/jboss-as/blob/master/build/src/main/resources/docs/schema/jboss-as-infinispan_1_0.xsd

For the jdbc cache stores, which come in 3 flavors, I've consolidated
them into a single configuration element jdbc-store/, where the
variant is implied the defined tables.  After providing default values
for all the required fields, we arrive at the following minimal
configuration:
e.g.
jdbc-store datasource=java:jboss/jdbc/somedatabase/

I started with the assumption that the database resource will always
come from an AS-managed DataSource.

To use a string-based jdbc store, we specify the type of table to use:
e.g.

jdbc-store datasource=java:jboss/jdbc/somedatabase
  entry-table/
/jdbc-store

Likewise, if we want to use a binary jdbc store:
e.g.
jdbc-store datasource=java:jboss/jdbc/somedatabase
  bucket-table/
/jdbc-store

Using both entry-table/ and bucket-table/ (or neither) indicates the
use of a mixed jdbc store.

The tables themselves are fully customizable (shown with their default
values):
e.g.
jdbc-store datasource=java:jboss/jdbc/somedatabase
 bucket-table prefix=ispn_bucket batch-size=100 fetch-size=100
  id-column name=id type=VARCHAR/
  data-column name=datum type=BINARY/
  timestamp-column name=version type=BIGINT/
 /bucket-table
 entry-table prefix=ispn_entry batch-size=100 fetch-size=100
  id-column name=id type=VARCHAR/
  data-column name=datum type=BINARY/
  timestamp-column name=version type=BIGINT/
 /entry-table
/jdbc-store


The schema for the remote cache store is far simpler.  You can specify a
specific remote cache name, server list, and hot rod client properties
are directly enumerated:
e.g.
remote-store cache=some-named-cache servers=127.0.0.1:11311
  property 
name=infinispan.client.hotrod.request_balancing_strategy.../property
/remote-store

If the cache attribute is omitted, we assume the default cache is to be
used.

Unfortunately, there doesn't seem to be a way to integrate the thread
pools used by RemoteCache/RemoteCacheManager with the AS7 threading
subsystem.  In order to do this, RemoteCacheStoreConfig would need
methods for providing ExecutorFactory implementations, similar to the
way GlobalConfiguration works.

I haven't started on the cloud-based store yet, as it's kind of a
dependency nightmare.

Thoughts?

Paul

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Request for feedback on cache store support in AS7 Infinispan subsystem

[Paul Ferraro]

- Original Message -
 From: Tristan Tarrant ttarr...@redhat.com
 To: infinispan-dev@lists.jboss.org
 Sent: Thursday, September 15, 2011 12:18:59 PM
 Subject: Re: [infinispan-dev] Request for feedback on cache store support in 
 AS7 Infinispan subsystem
 On 09/15/2011 05:34 PM, Paul Ferraro wrote:
  I've created a draft of what I thought could be workable schema for
  the
  remote and jdbc cache stores and would like some feedback.
 
  The amended Infinispan subsystem schema can be found here:
  https://github.com/pferraro/jboss-as/blob/master/build/src/main/resources/docs/schema/jboss-as-infinispan_1_0.xsd
 
  For the jdbc cache stores, which come in 3 flavors, I've
  consolidated
 
 Looks good. We need to document how a user can specify a custom key
 mapper. Would this be in the documentation annotation of the
 jdbc-store or provided elsewhere ?

The procedure for using a custom key mapper:
1. Add the following property to the jdbc-store/:
 property name=key2StringMapperclass.name.of.key.mapper/property
2. Add the jar file containing the above class and its dependencies to:
$JBOSS_HOME/modules/org/infinispan/main/.
3. Edit $JBOSS_HOME/modules/org/infinispan/main/modules.xml and add a reference 
to the jar within resources/.

I'll make sure this gets added to the docs.

  The schema for the remote cache store is far simpler. You can
  specify a
  specific remote cache name, server list, and hot rod client
  properties
  are directly enumerated:
  e.g.
  remote-store cache=some-named-cache servers=127.0.0.1:11311
 property
 name=infinispan.client.hotrod.request_balancing_strategy.../property
  /remote-store
 I see that you also exposed tcp_no_delay and socket_timeout in your
 latest code. Good.

Yep, those attributes are optional, whereas servers is required.

  I haven't started on the cloud-based store yet, as it's kind of a
  dependency nightmare.
 Do we really want to include the low-level cloud implementations as
 part
 of AS7 ? We don't provide JDBC drivers.

There are only 4, right?
We can certainly instruct users on the procedure to add the relevant cloud 
provider jar to the jclouds module.

 Tristan
 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] AS7 infinispan subsystem configurations for JDBC, Remote and Cloud cache stores

[Paul Ferraro]

On Fri, 2011-09-02 at 12:19 +0200, Galder Zamarreño wrote:
 On Sep 1, 2011, at 4:31 PM, Paul Ferraro wrote:
 
  On Thu, 2011-09-01 at 13:12 +0200, Galder Zamarreño wrote:
  Hey Paul,
  
  As shown by Martin in https://issues.jboss.org/browse/JBPAPP-6718 , it's 
  clear that the AS7 Infinispan subsystem is not yet ready to read 
  configurations for stores other than the FileCacheStore, so I'd assume 
  we'd need to create a new JIRA on AS7 to deal with configuration of:
  - JDBCCacheStore
  - RemoteCacheStore
  - CloudCacheStore
  
  As I mentioned in the jira, all EDG needs to do to support these is add
  the appopriate dependencies to the org.jboss.as.infinispan's module.xml.
 
 Hmmm, I don't see anywhere org.jboss.as.infinispan's module.xml. I see 
 org.jboss.as.clustering.infinispan's module.xml and I did not touch that.

Whoops.  Sorry for the confusion.

 In fact, if you see the JIRA, that's what's missing that Martin spotted (thx 
 Martin!)

Sorry, that was a sloppy (and incorrect) response on my part.  Let me be
more explicit.  So, there are actually 2 ways to go about this.

1. Create separate modules for each cache store implementation.  Add the
modules as dependencies to the module.xml for the org.infinispan module
(since these classes will be loaded by the infinispan module).

2. Add the maven artifacts for these cache stores directly to the
org.infinispan module.  This is done by modifying the main pom.xml (to
include the new maven artifacts), adding the dependencies again to
build/pom.xml (minus the version), and update the org.infinispan module
definition within build/build.xml (which specifies which artifacts
should be included in a given module) to include the new artifacts.
This is the approach that I attempted to suggest in the jira.

It seems you guys are trying to take the 1st approach, though I would
actually recommend taking the 2nd approach, since a) it's less
cumbersome b) the only reason to create separate modules per cache store
is if they were reusable by some other module other than the
org.infinispan module.

 Btw, if we take JDBCCacheStore as example, I did:
 
 - Create org.infinispan.loaders.jdbc module.xml and added these dependencies 
 there:
 dependencies
 module name=javax.api/
 module name=javax.transaction.api/
 module name=javax.xml.bind.api/
 module name=org.apache.xerces services=import/
 module name=org.infinispan/
 module name=org.jboss.logging/
 module name=org.jboss.marshalling/
 module name=org.jboss.marshalling.river services=import/
 module name=org.jgroups/
 module name=c3p0.c3p0/
 /dependencies
 
 Question: Once org.jboss.as.clustering.infinispan is updated, can 
 org.infinispan.loaders.jdbc's module.xml be simplified to only contain the 
 dependencies not already included in org.jboss.as.clustering.infinispan

No.  The way JBoss Modules works, each module needs to enumerate all of
its module dependencies, otherwise, you'll get NCDFErrors.
However, I don't recommend going this route anyway (see above).

  
  Looking at what you've done for the FCS, you seem to enable different type 
  of configs, i.e.
  
  file-store fetch-state=false passivation=false path=path 
  preload=true purge=false relative-to=jboss.server.temp.dir 
  shared=true singleton=true/
  
  vs
  
  store class=org.infinispan.loaders.file.FileCacheStore 
  fetch-state=true passivation=true preload=false purge=true 
  shared=false singleton=false
property name=location${java.io.tmpdir}/property
  /store
  
  I suspect the idea is to lean towards more strictly typed configurations 
  as shown in 1st example?
  
  There few a couple motivations at play here:
  
  The first was to comply with the AS7 configuration schema requirements,
  such that users should not need to define class names in the
  configuration file, unless referring to their own classes, or for less
  common use cases.
  This could have been achieved by enumerating the supported stores:
  e.g.
  store type=file/
  store type=jdbc/
  or via separate elements:
  file-store/
  jdbc-store/
  
  The motivation for going with the separate element approach was to make
  the supported cache store properties explicit, such that some properties
  could explicitly reference other subsystems.  For example, file-store
  leverage the paths subsystem (e.g. via the relative-to and path
  attributes) for defining the file system location - the advantage of
  which is the ability to manage paths from the cli/console.
  
  Several of these cache stores will also want to reference other AS
  services, e.g. JDBC cache store will want to reference a JCA data
  source.
  
  That said, for AS 7.1, I think we should figure out which cache stores
  constitute common use cases, expand the infinispan schema to support
  them, and fully document how one would go about using an adhoc cache
  store implementation.
 
 +1
 
 The set of cache stores has been pretty

Re: [infinispan-dev] AS7 infinispan subsystem configurations for JDBC, Remote and Cloud cache stores

[Paul Ferraro]

FYI:
https://issues.jboss.org/browse/AS7-1713
https://issues.jboss.org/browse/AS7-1714

I'll resolve AS7-1713 today.

On Fri, 2011-09-02 at 12:19 +0200, Galder Zamarreño wrote:
 On Sep 1, 2011, at 4:31 PM, Paul Ferraro wrote:
 
  On Thu, 2011-09-01 at 13:12 +0200, Galder Zamarreño wrote:
  Hey Paul,
  
  As shown by Martin in https://issues.jboss.org/browse/JBPAPP-6718 , it's 
  clear that the AS7 Infinispan subsystem is not yet ready to read 
  configurations for stores other than the FileCacheStore, so I'd assume 
  we'd need to create a new JIRA on AS7 to deal with configuration of:
  - JDBCCacheStore
  - RemoteCacheStore
  - CloudCacheStore
  
  As I mentioned in the jira, all EDG needs to do to support these is add
  the appopriate dependencies to the org.jboss.as.infinispan's module.xml.
 
 Hmmm, I don't see anywhere org.jboss.as.infinispan's module.xml. I see 
 org.jboss.as.clustering.infinispan's module.xml and I did not touch that.
 
 In fact, if you see the JIRA, that's what's missing that Martin spotted (thx 
 Martin!)
 
 Btw, if we take JDBCCacheStore as example, I did:
 
 - Create org.infinispan.loaders.jdbc module.xml and added these dependencies 
 there:
 dependencies
 module name=javax.api/
 module name=javax.transaction.api/
 module name=javax.xml.bind.api/
 module name=org.apache.xerces services=import/
 module name=org.infinispan/
 module name=org.jboss.logging/
 module name=org.jboss.marshalling/
 module name=org.jboss.marshalling.river services=import/
 module name=org.jgroups/
 module name=c3p0.c3p0/
 /dependencies
 
 Question: Once org.jboss.as.clustering.infinispan is updated, can 
 org.infinispan.loaders.jdbc's module.xml be simplified to only contain the 
 dependencies not already included in org.jboss.as.clustering.infinispan
 
  
  Looking at what you've done for the FCS, you seem to enable different type 
  of configs, i.e.
  
  file-store fetch-state=false passivation=false path=path 
  preload=true purge=false relative-to=jboss.server.temp.dir 
  shared=true singleton=true/
  
  vs
  
  store class=org.infinispan.loaders.file.FileCacheStore 
  fetch-state=true passivation=true preload=false purge=true 
  shared=false singleton=false
property name=location${java.io.tmpdir}/property
  /store
  
  I suspect the idea is to lean towards more strictly typed configurations 
  as shown in 1st example?
  
  There few a couple motivations at play here:
  
  The first was to comply with the AS7 configuration schema requirements,
  such that users should not need to define class names in the
  configuration file, unless referring to their own classes, or for less
  common use cases.
  This could have been achieved by enumerating the supported stores:
  e.g.
  store type=file/
  store type=jdbc/
  or via separate elements:
  file-store/
  jdbc-store/
  
  The motivation for going with the separate element approach was to make
  the supported cache store properties explicit, such that some properties
  could explicitly reference other subsystems.  For example, file-store
  leverage the paths subsystem (e.g. via the relative-to and path
  attributes) for defining the file system location - the advantage of
  which is the ability to manage paths from the cli/console.
  
  Several of these cache stores will also want to reference other AS
  services, e.g. JDBC cache store will want to reference a JCA data
  source.
  
  That said, for AS 7.1, I think we should figure out which cache stores
  constitute common use cases, expand the infinispan schema to support
  them, and fully document how one would go about using an adhoc cache
  store implementation.
 
 +1
 
 The set of cache stores has been pretty stable for a while now, so I'm 
 totally up for making the schema support the most common ones. In my view, 
 these are the three that I mentioned above plus file one.
 
 So, before 7.1, if we want to support this before that, the easiest would be 
 to rely on store/property combo until we have the most commonly used cache 
 stores properly supported? 
 
 If that's the case, is there anything extra that needs doing? The reason I 
 ask is cos you already support this format for FCS, so wondering if it should 
 work as is.
 
  
  Also, doing this would probably mean that these cache store jars and their 
  dependencies make it to AS7, right?
  
  Correct.
 
 Hmmm, then this needs to be resolved in AS7 really, doesn't it? If that's the 
 case, why modify EDG?
 
  
  Did you have any other plans for this? Or maybe you have other jiras 
  already for this?
  
  I don't believe one exists yet.  I'll create the relevant AS7 jiras for
  these today.
  
  Cheers,
  --
  Galder Zamarreño
  Sr. Software Engineer
  Infinispan, JBoss Cache
  
  
  
 
 --
 Galder Zamarreño
 Sr. Software Engineer
 Infinispan, JBoss Cache
 


___
infinispan-dev mailing list
infinispan-dev

Re: [infinispan-dev] AS7 infinispan subsystem configurations for JDBC, Remote and Cloud cache stores

[Paul Ferraro]

On Thu, 2011-09-01 at 13:12 +0200, Galder Zamarreño wrote:
 Hey Paul,
 
 As shown by Martin in https://issues.jboss.org/browse/JBPAPP-6718 , it's 
 clear that the AS7 Infinispan subsystem is not yet ready to read 
 configurations for stores other than the FileCacheStore, so I'd assume we'd 
 need to create a new JIRA on AS7 to deal with configuration of:
 - JDBCCacheStore
 - RemoteCacheStore
 - CloudCacheStore

As I mentioned in the jira, all EDG needs to do to support these is add
the appopriate dependencies to the org.jboss.as.infinispan's module.xml.

 Looking at what you've done for the FCS, you seem to enable different type of 
 configs, i.e.
 
 file-store fetch-state=false passivation=false path=path 
 preload=true purge=false relative-to=jboss.server.temp.dir 
 shared=true singleton=true/
 
 vs
 
 store class=org.infinispan.loaders.file.FileCacheStore fetch-state=true 
 passivation=true preload=false purge=true shared=false 
 singleton=false
property name=location${java.io.tmpdir}/property
 /store
 
 I suspect the idea is to lean towards more strictly typed configurations as 
 shown in 1st example?

There few a couple motivations at play here:

The first was to comply with the AS7 configuration schema requirements,
such that users should not need to define class names in the
configuration file, unless referring to their own classes, or for less
common use cases.
This could have been achieved by enumerating the supported stores:
e.g.
store type=file/
store type=jdbc/
or via separate elements:
file-store/
jdbc-store/

The motivation for going with the separate element approach was to make
the supported cache store properties explicit, such that some properties
could explicitly reference other subsystems.  For example, file-store
leverage the paths subsystem (e.g. via the relative-to and path
attributes) for defining the file system location - the advantage of
which is the ability to manage paths from the cli/console.

Several of these cache stores will also want to reference other AS
services, e.g. JDBC cache store will want to reference a JCA data
source.

That said, for AS 7.1, I think we should figure out which cache stores
constitute common use cases, expand the infinispan schema to support
them, and fully document how one would go about using an adhoc cache
store implementation.

 Also, doing this would probably mean that these cache store jars and their 
 dependencies make it to AS7, right?

Correct.

 Did you have any other plans for this? Or maybe you have other jiras already 
 for this?

I don't believe one exists yet.  I'll create the relevant AS7 jiras for
these today.

 Cheers,
 --
 Galder Zamarreño
 Sr. Software Engineer
 Infinispan, JBoss Cache
 


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Partial state transfer in Infinispan

[Paul Ferraro]

On Wed, 2011-06-01 at 16:46 +0200, Bela Ban wrote:
 
 On 6/1/11 4:21 PM, Sanne Grinovero wrote:
  Hi Bela,
 
  2011/6/1 Bela Banb...@redhat.com:
  We currently use JGroups' partial state transfer to transfer individual
  caches from one Infinispan instance to another.
 
  Since I got rid of partial state transfer in JGroups 3.0, and don't like
  to add it back, I'd like to know whether this is still needed.
 
  I thought that we currently require the same set of caches to be
  available in all Infinispan instances, and the reason (IIRC) was that
  distribution wouldn't work if we have caches 1 and 2 available on
  instances A and B, but not on C, because consistent hashing distributes
  the data based on views, and we didn't want to have to keep track of
  individual caches...
 
  Well I really don't like this limitation in Infinispan and was
  actually hoping that we could remove it at some point.
  Imagine the scenario in which you have a running cluster, and at some
  point the new release of your application needs an additional cache:
  there's no way to start a new node having this new cache.
 
 
 Yes, I fully agree. Another example is HTTP web sessions: currently 1 
 webapp == 1 cache, so we currently require the same webapps to be 
 deployed in all JBoss instances *if* we use replication (distribution is 
 different) !

As of AS7, web sessions for all webapps are stored in a single cache.
https://issues.jboss.org/browse/JBCLUSTER-293

  Also right now when an application starts, it's possible with the
  proper timing that it joins the cluster before having defined and
  started all caches (starting the cachemanager and the caches is not an
  atomic operation), basically failing to start because of this
  limitation.
 
 
 Yep
 
 
  Maybe it's still possible to build such a thing on top of non-partial
  state transfer? As it doesn't exist, we didn't design it.
 
 
 Yes. Well, Infinispan already uses its own state transfer for 
 distribution, I wonder why this isn't the case for replication.
 
 
  Why are we actually using JGroups' state transfer with replication, but
  use our own state transfer with distribution ?
 
  I don't know, but guess it's because each node has a different set of
  keys so no node has the same state as another ?
 
 You could still use JGroups state transfer; getState() would list the 
 state provider as target node.
 
 In general, partial state transfer involves transferring (1) the partial 
 state and (2) the digest, which is a vector of highest seqnos seen for 
 every member. When we get a partial state, we always overwrite our own 
 digest with the one received, and update our state accordingly. However, 
 when this is done a couple of times, for different partial states, I'm 
 not sure that we won't receive a few messages multiple times, due to the 
 digest overwriting...
 
 I think the cleanest solution would be for you guys to reuse the state 
 transfer you already use for state transfer in distribution mode.
 


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

[Paul Ferraro]

I had a hunch that might be the case - I'll hold off on testing until
ISPN-953 is resolved.
Thanks Galder,

Paul

On Thu, 2011-02-24 at 11:37 +0100, Galder Zamarreño wrote: 
 It's the result of https://issues.jboss.org/browse/ISPN-925 and 
 http://goo.gl/MUJaK
 
 I think it was an oversight. I agree that it should have been deprecated and 
 removed in Infinispan 6.0.
 
 I've created a JIRA to restore it and mark it as deprecated: 
 https://issues.jboss.org/browse/ISPN-953
 
 On Feb 23, 2011, at 6:00 PM, Paul Ferraro wrote:
 
  In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came
  across a NoSuchMethodError.  Specifically, a couple AS components
  utilize DistributionManager.isLocal(String), which was dropped from the
  public API sometime after 4.2.1.CR1.
  
  While the fix is trivial enough (in the end I'll need to perform several
  component release to compensate), this raises the larger issue of a API
  stability policy for major vs minor vs patch releases.  At the very
  least, I don't think its wise to remove methods from a public interface
  in a patch release.  In my opinion, removing methods from a public API
  should only happen across major releases, and even then, only after
  being formally deprecated.
  
  Thoughts?
  
  Paul
  
  ___
  infinispan-dev mailing list
  infinispan-dev@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@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev



___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

[infinispan-dev] ISPN-83 (FLUSH removal) causing state transfer timeouts

[Paul Ferraro]

After testing AS6 with Infinispan 4.2.1.CR3, I started seeing a slew of
testsuite failures all due to state transfer timeouts.  These are
REPL_SYNC tests, with state transfer enabled:
e.g.

2011-02-23 10:59:46,771 DEBUG 
[org.infinispan.statetransfer.StateTransferManagerImpl] Initiating state 
transfer process
2011-02-23 10:59:46,771 INFO  [org.infinispan.remoting.rpc.RpcManagerImpl] 
Trying to fetch state from T510-29294
2011-02-23 10:59:46,773 DEBUG 
[org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] GET_STATE: asking 
T510-29294 for state, passing down a SUSPEND_STABLE event, timeout=1
2011-02-23 10:59:46,773 DEBUG [org.jgroups.protocols.pbcast.STABLE] suspending 
message garbage collection
2011-02-23 10:59:46,773 DEBUG [org.jgroups.protocols.pbcast.STABLE] resume task 
started, max_suspend_time=11000
2011-02-23 10:59:46,778 DEBUG 
[org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] 
StateProviderThreadSpawner listening at 192.168.0.3:37173...
2011-02-23 10:59:46,778 DEBUG 
[org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] Responding to state 
requester T510-23375 with address 192.168.0.3:37173 and digest T510-23375: [0 : 
0 (0)], T510-29294: [0 : 1 (1)]
2011-02-23 10:59:46,781 DEBUG [org.jgroups.protocols.pbcast.NAKACK]
[overwriteDigest()]
existing digest:  T510-23375: [0 : 0 (0)], T510-29294: [0 : 1 (1)]
new digest:   T510-29294: [0 : 1 (1)], T510-23375: [0 : 0 (0)]
resulting digest: T510-23375: [0 : 0 (0)], T510-29294: [0 : 1 (1)]
2011-02-23 10:59:46,781 DEBUG 
[org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] Connecting to state 
provider /192.168.0.3:37173, original buffer size was 43690 and was reset to 
8192
2011-02-23 10:59:46,782 DEBUG 
[org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] Connected to state 
provider, my end of the socket is /192.168.0.3:38305 passing inputstream up...
2011-02-23 10:59:46,783 DEBUG 
[org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] 
StateProviderThreadSpawner listening at 192.168.0.3:37173...
2011-02-23 10:59:46,783 DEBUG 
[org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] Accepted request for 
state transfer from /192.168.0.3:38305 handing of to PooledExecutor thread
2011-02-23 10:59:46,786 DEBUG 
[org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] Running on 
Thread[STREAMING_STATE_TRANSFER-sender-1,T510-29294,5,JGroups]. Accepted 
request for state transfer from /192.168.0.3:38305, original buffer size was 
25434 and was reset to 8192, passing outputstream up...
2011-02-23 10:59:46,789 DEBUG 
[org.infinispan.statetransfer.StateTransferManagerImpl] Applying state
2011-02-23 10:59:46,789 DEBUG 
[org.infinispan.statetransfer.StateTransferManagerImpl] Generating state.  Can 
provide? true
2011-02-23 10:59:46,822 DEBUG 
[org.infinispan.statetransfer.StateTransferManagerImpl] Writing 0 StoredEntries 
to stream
2011-02-23 10:59:46,833 DEBUG 
[org.infinispan.statetransfer.StateTransferManagerImpl] State generated, 
closing object stream
2011-02-23 10:59:46,834 DEBUG 
[org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] State writer is closing 
the socket
2011-02-23 10:59:56,774 DEBUG [org.jgroups.protocols.pbcast.STABLE] resuming 
message garbage collection
2011-02-23 10:59:56,834 WARN  [org.infinispan.remoting.rpc.RpcManagerImpl] 
Could not find available peer for state, backing off and retrying
2011-02-23 10:59:56,837 ERROR 
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] Caught while 
requesting or applying state
org.infinispan.statetransfer.StateTransferException: 
org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds 
waiting for a response from T510-29294
at 
org.infinispan.statetransfer.StateTransferManagerImpl.applyState(StateTransferManagerImpl.java:332)
at 
org.infinispan.remoting.InboundInvocationHandlerImpl.applyState(InboundInvocationHandlerImpl.java:199)
at 
org.infinispan.remoting.transport.jgroups.JGroupsTransport.setState(JGroupsTransport.java:582)
at 
org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:712)
at 
org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:772)
at org.jgroups.JChannel.up(JChannel.java:1422)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:954)
at 
org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER.connectToStateProvider(STREAMING_STATE_TRANSFER.java:525)
at 
org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER.handleStateRsp(STREAMING_STATE_TRANSFER.java:464)
at 
org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER.up(STREAMING_STATE_TRANSFER.java:225)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:190)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:419)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:401)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:888)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
at 

[infinispan-dev] API stability policy for major vs minor vs patch releases

[Paul Ferraro]

In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came
across a NoSuchMethodError.  Specifically, a couple AS components
utilize DistributionManager.isLocal(String), which was dropped from the
public API sometime after 4.2.1.CR1.

While the fix is trivial enough (in the end I'll need to perform several
component release to compensate), this raises the larger issue of a API
stability policy for major vs minor vs patch releases.  At the very
least, I don't think its wise to remove methods from a public interface
in a patch release.  In my opinion, removing methods from a public API
should only happen across major releases, and even then, only after
being formally deprecated.

Thoughts?

Paul

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] ISPN-83 (FLUSH removal) causing state transfer timeouts

[Paul Ferraro]

CR2 was unusable for me because of ISPN-934.

On Wed, 2011-02-23 at 11:54 -0500, Vladimir Blagojevic wrote:
 Paul,
 
 How is the testsuite tolerating 4.2.1CR2? I removed FLUSH in CR2 release 
 [1].
 
 Vladimir
 
 [1] https://issues.jboss.org/browse/ISPN-83
 
 
 On 11-02-23 11:18 AM, Paul Ferraro wrote:
  After testing AS6 with Infinispan 4.2.1.CR3, I started seeing a slew of
  testsuite failures all due to state transfer timeouts.  These are
  REPL_SYNC tests, with state transfer enabled:
  e.g.
 
  2011-02-23 10:59:46,771 DEBUG 
  [org.infinispan.statetransfer.StateTransferManagerImpl] Initiating state 
  transfer process
  2011-02-23 10:59:46,771 INFO  [org.infinispan.remoting.rpc.RpcManagerImpl] 
  Trying to fetch state from T510-29294
  2011-02-23 10:59:46,773 DEBUG 
  [org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] GET_STATE: asking 
  T510-29294 for state, passing down a SUSPEND_STABLE event, timeout=1
  2011-02-23 10:59:46,773 DEBUG [org.jgroups.protocols.pbcast.STABLE] 
  suspending message garbage collection
  2011-02-23 10:59:46,773 DEBUG [org.jgroups.protocols.pbcast.STABLE] resume 
  task started, max_suspend_time=11000
  2011-02-23 10:59:46,778 DEBUG 
  [org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] 
  StateProviderThreadSpawner listening at 192.168.0.3:37173...
  2011-02-23 10:59:46,778 DEBUG 
  [org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] Responding to state 
  requester T510-23375 with address 192.168.0.3:37173 and digest T510-23375: 
  [0 : 0 (0)], T510-29294: [0 : 1 (1)]
  2011-02-23 10:59:46,781 DEBUG [org.jgroups.protocols.pbcast.NAKACK]
  [overwriteDigest()]
  existing digest:  T510-23375: [0 : 0 (0)], T510-29294: [0 : 1 (1)]
  new digest:   T510-29294: [0 : 1 (1)], T510-23375: [0 : 0 (0)]
  resulting digest: T510-23375: [0 : 0 (0)], T510-29294: [0 : 1 (1)]
  2011-02-23 10:59:46,781 DEBUG 
  [org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] Connecting to state 
  provider /192.168.0.3:37173, original buffer size was 43690 and was reset 
  to 8192
  2011-02-23 10:59:46,782 DEBUG 
  [org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] Connected to state 
  provider, my end of the socket is /192.168.0.3:38305 passing inputstream 
  up...
  2011-02-23 10:59:46,783 DEBUG 
  [org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] 
  StateProviderThreadSpawner listening at 192.168.0.3:37173...
  2011-02-23 10:59:46,783 DEBUG 
  [org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] Accepted request 
  for state transfer from /192.168.0.3:38305 handing of to PooledExecutor 
  thread
  2011-02-23 10:59:46,786 DEBUG 
  [org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] Running on 
  Thread[STREAMING_STATE_TRANSFER-sender-1,T510-29294,5,JGroups]. Accepted 
  request for state transfer from /192.168.0.3:38305, original buffer size 
  was 25434 and was reset to 8192, passing outputstream up...
  2011-02-23 10:59:46,789 DEBUG 
  [org.infinispan.statetransfer.StateTransferManagerImpl] Applying state
  2011-02-23 10:59:46,789 DEBUG 
  [org.infinispan.statetransfer.StateTransferManagerImpl] Generating state.  
  Can provide? true
  2011-02-23 10:59:46,822 DEBUG 
  [org.infinispan.statetransfer.StateTransferManagerImpl] Writing 0 
  StoredEntries to stream
  2011-02-23 10:59:46,833 DEBUG 
  [org.infinispan.statetransfer.StateTransferManagerImpl] State generated, 
  closing object stream
  2011-02-23 10:59:46,834 DEBUG 
  [org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER] State writer is 
  closing the socket
  2011-02-23 10:59:56,774 DEBUG [org.jgroups.protocols.pbcast.STABLE] 
  resuming message garbage collection
  2011-02-23 10:59:56,834 WARN  [org.infinispan.remoting.rpc.RpcManagerImpl] 
  Could not find available peer for state, backing off and retrying
  2011-02-23 10:59:56,837 ERROR 
  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] Caught while 
  requesting or applying state
  org.infinispan.statetransfer.StateTransferException: 
  org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds 
  waiting for a response from T510-29294
   at 
  org.infinispan.statetransfer.StateTransferManagerImpl.applyState(StateTransferManagerImpl.java:332)
   at 
  org.infinispan.remoting.InboundInvocationHandlerImpl.applyState(InboundInvocationHandlerImpl.java:199)
   at 
  org.infinispan.remoting.transport.jgroups.JGroupsTransport.setState(JGroupsTransport.java:582)
   at 
  org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:712)
   at 
  org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:772)
   at org.jgroups.JChannel.up(JChannel.java:1422)
   at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:954)
   at 
  org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER.connectToStateProvider(STREAMING_STATE_TRANSFER.java:525