[JBoss JIRA] (ISPN-3738) Entry version gets lost during topology change -> NPE
by Radim Vansa (JIRA)
Radim Vansa created ISPN-3738:
---------------------------------
Summary: Entry version gets lost during topology change -> NPE
Key: ISPN-3738
URL: https://issues.jboss.org/browse/ISPN-3738
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 6.0.0.Final
Reporter: Radim Vansa
Assignee: Mircea Markus
Priority: Critical
Replicated TX cache with WSC, A, B are in cluster, C is joining
0. The current CH already contains A and B as owners, C is joining (is not primary owner of anything yet). B is primary owner of K=V.
1. A sends PrepareCommand to B and C with put(K, V) (V is null on all nodes)
2. C receives PrepareCommand and responds with no versions (it is not primary owner)
3. topology changes on B - primary ownership of K is transfered to C
4. B receives PrepareCommand, responds without K's version (it is not primary)
5. B forwards the Prepare to C as it sees that the command has lower topology ID
6. C responds to B's prepare with version of K
7. K version is *not* added to B's response, B responds to A
8. A finds out that topology has changed, forwards prepare to C
9. C responds to C's prepare with version of K
10. A receives C's response, but the versions are not added to transaction
11. A sends out CommitCommand missing version of K
12. all nodes record K=V without version as usual ImmortalCacheEntry
13. the next time we try to increase version of K=V, we fail with NPE in SimpleClusteredVersionGenerator (actually when it tries to throw IllegalArgumentException because the null version is unexpected version class)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (ISPN-3270) Hotrod clients removeWithVersion doesn't work with replicated cache
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3270?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3270:
-----------------------------------------------
Jakub Markos <jmarkos(a)redhat.com> changed the Status of [bug 987440|https://bugzilla.redhat.com/show_bug.cgi?id=987440] from ON_QA to VERIFIED
> Hotrod clients removeWithVersion doesn't work with replicated cache
> -------------------------------------------------------------------
>
> Key: ISPN-3270
> URL: https://issues.jboss.org/browse/ISPN-3270
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 6.0.0.Beta1
> Reporter: Jakub Markos
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 620
> Attachments: server-trace-logs.zip
>
>
> I have a cluster of 2 latest infinispan servers (6.0.0-SNAPSHOT) with the following container configuration:
> {code:xml}<cache-container name="default" default-cache="default" listener-executor="infinispan-listener">
> <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/>
> <replicated-cache name="default" start="EAGER" mode="SYNC" batching="false" remote-timeout="60000">
> <transaction mode="NONE"/>
> <state-transfer enabled="true" timeout="60000"/>
> </replicated-cache>
> </cache-container>
> {code}
> Running this code:
> {code} remoteCache = remoteCacheManager.getCache();
> remoteCache.clear();
> assertFalse(remoteCache.removeWithVersion("aKey", 12321212l));
> remoteCache.put("aKey", "aValue");
> VersionedValue valueBinary = remoteCache.getVersioned("aKey");
> System.out.println("value = " + valueBinary.getValue());
> System.out.println("version = " + valueBinary.getVersion());
> System.out.println(remoteCache.removeWithVersion("aKey",valueBinary.getVersion()));
> valueBinary = remoteCache.getVersioned("aKey");
> System.out.println("value = " + valueBinary.getValue());
> System.out.println("version = " + valueBinary.getVersion());
> {code}
> results most of the time in (and the other times the removeWithVersion returns false)
> {quote}
> value = aValue
> version = 281483566645249
> true
> value = aValue
> version = 281483566645249
> {quote}
> The command works with distributed/local cache.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (ISPN-3454) Hot Rod client doesn't retry operation on RemoteException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3454?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3454:
-----------------------------------------------
Michal Linhard <mlinhard(a)redhat.com> changed the Status of [bug 1002957|https://bugzilla.redhat.com/show_bug.cgi?id=1002957] from ON_QA to VERIFIED
> Hot Rod client doesn't retry operation on RemoteException
> ---------------------------------------------------------
>
> Key: ISPN-3454
> URL: https://issues.jboss.org/browse/ISPN-3454
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.Final, 6.0.0.Alpha3
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> This is a client-side problem.
> In a resilience test with 4 nodes where 1 is killed, I'm getting a lot of these:
> {code}
> 08:30:55,198 ERROR [org.jboss.smartfrog.jdg.loaddriver.DriverThread] (DriverThread-369) Error doing: PUT key399869 to node node04, took 493 ms
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[821188] returned server error (status=0x85): org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node01/default, see cause for remote stack trace
> at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143)
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:209)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
> at org.jboss.qa.jdg.adapter.Infinispan60Adapter$HotRodRemoteCacheAdapter.put(Infinispan60Adapter.java:269)
> at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.makeRequest(DriverThreadImpl.java:265)
> at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.run(DriverThreadImpl.java:378)
> {code}
> Isn't this a recoverable problem that shouldn't be left to user to handle ?
> source:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/RESILIENCE...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (ISPN-3454) Hot Rod client doesn't retry operation on RemoteException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3454?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3454:
-----------------------------------------------
Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 1002957|https://bugzilla.redhat.com/show_bug.cgi?id=1002957]
Verified for 6.2.0.ER4
> Hot Rod client doesn't retry operation on RemoteException
> ---------------------------------------------------------
>
> Key: ISPN-3454
> URL: https://issues.jboss.org/browse/ISPN-3454
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.Final, 6.0.0.Alpha3
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> This is a client-side problem.
> In a resilience test with 4 nodes where 1 is killed, I'm getting a lot of these:
> {code}
> 08:30:55,198 ERROR [org.jboss.smartfrog.jdg.loaddriver.DriverThread] (DriverThread-369) Error doing: PUT key399869 to node node04, took 493 ms
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[821188] returned server error (status=0x85): org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node01/default, see cause for remote stack trace
> at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143)
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:209)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
> at org.jboss.qa.jdg.adapter.Infinispan60Adapter$HotRodRemoteCacheAdapter.put(Infinispan60Adapter.java:269)
> at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.makeRequest(DriverThreadImpl.java:265)
> at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.run(DriverThreadImpl.java:378)
> {code}
> Isn't this a recoverable problem that shouldn't be left to user to handle ?
> source:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/RESILIENCE...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño reassigned ISPN-3316:
--------------------------------------
Assignee: Galder Zamarreño (was: Tristan Tarrant)
> CDI Cache interceptor tests are failing while running in EAP container
> ----------------------------------------------------------------------
>
> Key: ISPN-3316
> URL: https://issues.jboss.org/browse/ISPN-3316
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.3.0.Final
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
> Labels: 620
>
> While migration of the CDI related tests to work under EAP container (at the moment using 6.0.GA), it was found that the tests related to interceptors are failing. The issue relates to
> org.infinispan.cdi.test.interceptor.CachePutInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveAllInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveInterceptorTest, org.infinispan.cdi.test.interceptor.CacheResultInterceptorTest.
> The failure relates to assertions. The thing is that all actions which are done using javax.cache.cache-api annotations, work properly (I've added some logs e.g. in CachePutInterceptor, and it shows that the data is put to the cache properly).
> But later when the test wants to verify that the data is really put to the data, retrieves the cache from the injected CacheContainer, the cache is empty - the data is not there.
> The issue appeared since the latest changes to the Infinispan-CDI module, and split to infinispan-jcache module. For the previous version, the tests are passed under EAP container.
> The example above was given for the CachePutInterceptorTest, but the same refers to the rest of them.
> The git repo for the sources, will be provided later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3316:
-----------------------------------
Fix Version/s: 6.1.0.Final
> CDI Cache interceptor tests are failing while running in EAP container
> ----------------------------------------------------------------------
>
> Key: ISPN-3316
> URL: https://issues.jboss.org/browse/ISPN-3316
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.3.0.Final
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> While migration of the CDI related tests to work under EAP container (at the moment using 6.0.GA), it was found that the tests related to interceptors are failing. The issue relates to
> org.infinispan.cdi.test.interceptor.CachePutInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveAllInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveInterceptorTest, org.infinispan.cdi.test.interceptor.CacheResultInterceptorTest.
> The failure relates to assertions. The thing is that all actions which are done using javax.cache.cache-api annotations, work properly (I've added some logs e.g. in CachePutInterceptor, and it shows that the data is put to the cache properly).
> But later when the test wants to verify that the data is really put to the data, retrieves the cache from the injected CacheContainer, the cache is empty - the data is not there.
> The issue appeared since the latest changes to the Infinispan-CDI module, and split to infinispan-jcache module. For the previous version, the tests are passed under EAP container.
> The example above was given for the CachePutInterceptorTest, but the same refers to the rest of them.
> The git repo for the sources, will be provided later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3316:
-----------------------------------
Affects Version/s: 6.0.0.Final
> CDI Cache interceptor tests are failing while running in EAP container
> ----------------------------------------------------------------------
>
> Key: ISPN-3316
> URL: https://issues.jboss.org/browse/ISPN-3316
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.3.0.Final, 6.0.0.Final
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> While migration of the CDI related tests to work under EAP container (at the moment using 6.0.GA), it was found that the tests related to interceptors are failing. The issue relates to
> org.infinispan.cdi.test.interceptor.CachePutInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveAllInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveInterceptorTest, org.infinispan.cdi.test.interceptor.CacheResultInterceptorTest.
> The failure relates to assertions. The thing is that all actions which are done using javax.cache.cache-api annotations, work properly (I've added some logs e.g. in CachePutInterceptor, and it shows that the data is put to the cache properly).
> But later when the test wants to verify that the data is really put to the data, retrieves the cache from the injected CacheContainer, the cache is empty - the data is not there.
> The issue appeared since the latest changes to the Infinispan-CDI module, and split to infinispan-jcache module. For the previous version, the tests are passed under EAP container.
> The example above was given for the CachePutInterceptorTest, but the same refers to the rest of them.
> The git repo for the sources, will be provided later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3316:
----------------------------------------
@Anna, @Tristan, this went under the radar somehow. We discovered the same thing via a different path: quickstarts, in ISPN-3735.
@Anna, I'm currently working on a fix for this. Could you port over the tests you created in jdg-funbtional-tests to Infinispan Server?
> CDI Cache interceptor tests are failing while running in EAP container
> ----------------------------------------------------------------------
>
> Key: ISPN-3316
> URL: https://issues.jboss.org/browse/ISPN-3316
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.3.0.Final
> Reporter: Anna Manukyan
> Assignee: Tristan Tarrant
> Labels: 620
>
> While migration of the CDI related tests to work under EAP container (at the moment using 6.0.GA), it was found that the tests related to interceptors are failing. The issue relates to
> org.infinispan.cdi.test.interceptor.CachePutInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveAllInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveInterceptorTest, org.infinispan.cdi.test.interceptor.CacheResultInterceptorTest.
> The failure relates to assertions. The thing is that all actions which are done using javax.cache.cache-api annotations, work properly (I've added some logs e.g. in CachePutInterceptor, and it shows that the data is put to the cache properly).
> But later when the test wants to verify that the data is really put to the data, retrieves the cache from the injected CacheContainer, the cache is empty - the data is not there.
> The issue appeared since the latest changes to the Infinispan-CDI module, and split to infinispan-jcache module. For the previous version, the tests are passed under EAP container.
> The example above was given for the CachePutInterceptorTest, but the same refers to the rest of them.
> The git repo for the sources, will be provided later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months