[JBoss JIRA] (ISPN-6563) If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6563?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6563:
----------------------------------
Fix Version/s: 8.2.2.Final
> If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6563
> URL: https://issues.jboss.org/browse/ISPN-6563
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final
>
>
> If an application use the javax.cache JCache API together with the infinispan-jcache-remote library the CacheManager is created with defaults.
> But it is expected that the hotrod-client.properties are used to configure the remote connection.
> The code is like this:
> {
> import javax.cache.*;
> ...
> CachingProvider jcacheProvider = Caching.getCachingProvider();
> CacheManager cacheManager = jcacheProvider.getCacheManager();
> }
> The org.infinispan.jcache.AbstractJCachingProvider use the org.infinispan.jcache.remote.CacheManger but does not provide properties.
> Therefor the CacheManager is constructed with the default of localhost:11222 as the configuration is not loaded from the properties file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-6563) If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6563?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6563:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6563
> URL: https://issues.jboss.org/browse/ISPN-6563
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final
>
>
> If an application use the javax.cache JCache API together with the infinispan-jcache-remote library the CacheManager is created with defaults.
> But it is expected that the hotrod-client.properties are used to configure the remote connection.
> The code is like this:
> {
> import javax.cache.*;
> ...
> CachingProvider jcacheProvider = Caching.getCachingProvider();
> CacheManager cacheManager = jcacheProvider.getCacheManager();
> }
> The org.infinispan.jcache.AbstractJCachingProvider use the org.infinispan.jcache.remote.CacheManger but does not provide properties.
> Therefor the CacheManager is constructed with the default of localhost:11222 as the configuration is not loaded from the properties file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (HRJS-9) Remove listener not working in cluster
by Galder Zamarreño (JIRA)
Galder Zamarreño created HRJS-9:
-----------------------------------
Summary: Remove listener not working in cluster
Key: HRJS-9
URL: https://issues.jboss.org/browse/HRJS-9
Project: Infinispan Javascript client
Issue Type: Bug
Affects Versions: 0.2.0
Reporter: Galder Zamarreño
Removing listener not working in a cluster. The problem is most likely due to routing since the remove listener should remove it from the node where it was added, so it needs to keep around the node address where the client listener add was invoked. Right now there's no such guarantee.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-6573) Functional API does not work [correctly] in transaction context
by Krzysztof Sobolewski (JIRA)
[ https://issues.jboss.org/browse/ISPN-6573?page=com.atlassian.jira.plugin.... ]
Krzysztof Sobolewski updated ISPN-6573:
---------------------------------------
Attachment: AbstractFunctionalInMemoryTest.java
FunctionalInMemoryTestTx.java
FunctionalInMemoryTestNonTx.java
Answering to https://developer.jboss.org/message/955416#955416 ("Is this an issue only when cache store is involved, or are the functional operations broken in transactional mode completely?"): yes, it's broken in transactional mode completely. I'm attaching tests that illustrate this. FunctionalInMemoryNonTx passes, while FunctionalInMemoryTx fails.
> Functional API does not work [correctly] in transaction context
> ---------------------------------------------------------------
>
> Key: ISPN-6573
> URL: https://issues.jboss.org/browse/ISPN-6573
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.1.Final
> Reporter: Krzysztof Sobolewski
> Attachments: AbstractFunctionalCachestoreTest.java, AbstractFunctionalInMemoryTest.java, FunctionalCachestoreTestNonTx.java, FunctionalCachestoreTestTx.java, FunctionalInMemoryTestNonTx.java, FunctionalInMemoryTestTx.java
>
>
> What is needed: a functional write operation on a key on a node that is not the key's owner, with cache loader enabled. What happens then is in non-transactional context it works fine; It starts failing when the functional operation is done in a transaction. Looks like the entry is wrapped prematurely, which puts it into the context's looked up nodes with the null value; the cache loader skips because the key is not local; and when it reaches Command.perform(), it still has null value. In the non-tx context this works OK because the command returns early if the entry is null (not wrapped) and then it is properly sent across the cluster. But in tx context it gets confused and invokes the functional operation on the local node even if it's not the owner. The functional operation gets an empty entry even though the cache loader would load it. It then modifies the entry, but the modification is not propagated anywhere because the tx distribution interceptor... well, because it doesn't handle this command at all? And the change is (apparently) not committed on the local node because it's not an owner.
> Oh, and if the node *is* an owner it doesn't help :)
> The tests are also available at https://gist.github.com/ksobolew/74bb8ff6b321786e64a62ecd0e4c5878/836905d...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-6576) Functional API does not load values from cache loader on non-primary owners
by Krzysztof Sobolewski (JIRA)
[ https://issues.jboss.org/browse/ISPN-6576?page=com.atlassian.jira.plugin.... ]
Krzysztof Sobolewski commented on ISPN-6576:
--------------------------------------------
Yes, that's the problem. I assume the idea of this API is that the function is replicated to all the owners (primary and backup) and executed there, modifying the local value, without the need to replicate the result (or, actually, to *avoid* the replication of final values). That way I can achieve what deltas would do - the function is the delta, in other words.
> Functional API does not load values from cache loader on non-primary owners
> ---------------------------------------------------------------------------
>
> Key: ISPN-6576
> URL: https://issues.jboss.org/browse/ISPN-6576
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.1.Final
> Reporter: Krzysztof Sobolewski
> Attachments: AbstractFunctionalCachestoreTest.java, AbstractFunctionalCachestoreTest.java, FunctionalCachestoreTestNonTx.java, FunctionalCachestoreTestTx.java
>
>
> We have a cluster in DIST mode with numOwners > 1, so there are primary and secondary owners, with persistence enabled. When I do a read-write operation on the cluster using the Functional API on a key that is present in the cache loader, the entry that gets passed to the functional operation has a non-null value only for the primary owner. See:
> org.infinispan.interceptors.ClusteredCacheLoaderInterceptor.skipLoadForWriteCommand()
> line 53.
> This is using non-transactional cache.
> NOTE: The attached tests are modified version of the ones in ISPN-6573.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-6576) Functional API does not load values from cache loader on non-primary owners
by Krzysztof Sobolewski (JIRA)
[ https://issues.jboss.org/browse/ISPN-6576?page=com.atlassian.jira.plugin.... ]
Krzysztof Sobolewski updated ISPN-6576:
---------------------------------------
Attachment: AbstractFunctionalCachestoreTest.java
Slightly modified test case with better filtering of owners and non-owners.
> Functional API does not load values from cache loader on non-primary owners
> ---------------------------------------------------------------------------
>
> Key: ISPN-6576
> URL: https://issues.jboss.org/browse/ISPN-6576
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.1.Final
> Reporter: Krzysztof Sobolewski
> Attachments: AbstractFunctionalCachestoreTest.java, AbstractFunctionalCachestoreTest.java, FunctionalCachestoreTestNonTx.java, FunctionalCachestoreTestTx.java
>
>
> We have a cluster in DIST mode with numOwners > 1, so there are primary and secondary owners, with persistence enabled. When I do a read-write operation on the cluster using the Functional API on a key that is present in the cache loader, the entry that gets passed to the functional operation has a non-null value only for the primary owner. See:
> org.infinispan.interceptors.ClusteredCacheLoaderInterceptor.skipLoadForWriteCommand()
> line 53.
> This is using non-transactional cache.
> NOTE: The attached tests are modified version of the ones in ISPN-6573.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months