[JBoss JIRA] (ISPN-2761) Write tests for the RHQ plugin
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2761?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2761:
----------------------------------
Assignee: William Burns (was: Tristan Tarrant)
> Write tests for the RHQ plugin
> ------------------------------
>
> Key: ISPN-2761
> URL: https://issues.jboss.org/browse/ISPN-2761
> Project: Infinispan
> Issue Type: Task
> Components: JMX, reporting and management
> Affects Versions: 5.2.0.CR3
> Reporter: Dan Berindei
> Assignee: William Burns
>
> The RHQ plugin doesn't have any functional tests at the moment. The InfinispanRhqTest class just starts a cache manager and waits for someone to start RHQ manually and connect to it.
> Instead we should have a test that creates a {{CacheComponent}} instance and invokes several operations on it, reads attributes etc.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3348) Unable to read entries from SingleFileCacheStore after server restart
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3348?page=com.atlassian.jira.plugin.... ]
Martin Gencur commented on ISPN-3348:
-------------------------------------
Might be related to ISPN-3298
> Unable to read entries from SingleFileCacheStore after server restart
> ---------------------------------------------------------------------
>
> Key: ISPN-3348
> URL: https://issues.jboss.org/browse/ISPN-3348
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.Alpha1
> Reporter: Martin Gencur
> Assignee: Tristan Tarrant
>
> Using the following configuration:
> {code:xml}
> <subsystem xmlns="urn:infinispan:server:core:5.3" default-cache-container="default">
> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener" eviction-executor="infinispan-eviction" replication-queue-executor="infinispan-repl-queue">
> <local-cache name="default" start="EAGER">
> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/>
> <transaction mode="NONE"/>
> <store class="org.infinispan.loaders.file.SingleFileCacheStore" passivation="false" preload="false" purge="false">
> <property name="location">${java.io.tmpdir}/single-file-cache-store</property>
> <property name="maxEntries">2</property>
> </store>
> </local-cache>
> </cache-container>
> </subsystem>
> {code}
> ...it is not possible to retrieve the cache entry from the cache store after server restart, as demonstrated by the following test:
> {code:java}
> RemoteCache<String, String> rc = rcm.getCache();
> rc.clear();
> assertNull(rc.get("k1"));
> rc.put("k1", "v1");
> rc.put("k2", "v2");
> rc.put("k3", "v3");
> assertEquals("v1", rc.get("k1"));
> assertEquals("v2", rc.get("k2"));
> assertEquals("v3", rc.get("k3"));
> controller.kill(CONTAINER);
> controller.start(CONTAINER);
> assertEquals("v2", rc.get("k2"));
> //^^^fails here - unable to find k2
> assertEquals("v3", rc.get("k3"));
> assertNull(rc.get("k1")); //maxEntries was 2, this entry should be lost as the oldest entries are removed
> controller.stop(CONTAINER);
> {code}
> Note that preload is set to false for this test. When I set it to true, the test passes.
> I tried to modify BaseCacheStoreFunctionalTest#testPreloadAndExpiry, disable "preload" and retrieve the cache entries after server restart by calling cache.get() (not from DataContainer) and the test passed (I ran SingleFileCacheStoreFunctionalTest which extends BaseCacheStoreFunctionalTest). So it seems the bug is related to the server distribution.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3348) Unable to read entries from SingleFileCacheStore after server restart
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3348?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3348:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> made a comment on [bug 986941|https://bugzilla.redhat.com/show_bug.cgi?id=986941]
Affects JDG 6.2.0 DR1
> Unable to read entries from SingleFileCacheStore after server restart
> ---------------------------------------------------------------------
>
> Key: ISPN-3348
> URL: https://issues.jboss.org/browse/ISPN-3348
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.Alpha1
> Reporter: Martin Gencur
> Assignee: Tristan Tarrant
>
> Using the following configuration:
> {code:xml}
> <subsystem xmlns="urn:infinispan:server:core:5.3" default-cache-container="default">
> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener" eviction-executor="infinispan-eviction" replication-queue-executor="infinispan-repl-queue">
> <local-cache name="default" start="EAGER">
> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/>
> <transaction mode="NONE"/>
> <store class="org.infinispan.loaders.file.SingleFileCacheStore" passivation="false" preload="false" purge="false">
> <property name="location">${java.io.tmpdir}/single-file-cache-store</property>
> <property name="maxEntries">2</property>
> </store>
> </local-cache>
> </cache-container>
> </subsystem>
> {code}
> ...it is not possible to retrieve the cache entry from the cache store after server restart, as demonstrated by the following test:
> {code:java}
> RemoteCache<String, String> rc = rcm.getCache();
> rc.clear();
> assertNull(rc.get("k1"));
> rc.put("k1", "v1");
> rc.put("k2", "v2");
> rc.put("k3", "v3");
> assertEquals("v1", rc.get("k1"));
> assertEquals("v2", rc.get("k2"));
> assertEquals("v3", rc.get("k3"));
> controller.kill(CONTAINER);
> controller.start(CONTAINER);
> assertEquals("v2", rc.get("k2"));
> //^^^fails here - unable to find k2
> assertEquals("v3", rc.get("k3"));
> assertNull(rc.get("k1")); //maxEntries was 2, this entry should be lost as the oldest entries are removed
> controller.stop(CONTAINER);
> {code}
> Note that preload is set to false for this test. When I set it to true, the test passes.
> I tried to modify BaseCacheStoreFunctionalTest#testPreloadAndExpiry, disable "preload" and retrieve the cache entries after server restart by calling cache.get() (not from DataContainer) and the test passed (I ran SingleFileCacheStoreFunctionalTest which extends BaseCacheStoreFunctionalTest). So it seems the bug is related to the server distribution.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3348) Unable to read entries from SingleFileCacheStore after server restart
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3348?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3348:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> made a comment on [bug 986941|https://bugzilla.redhat.com/show_bug.cgi?id=986941]
More information at https://issues.jboss.org/browse/ISPN-3348
> Unable to read entries from SingleFileCacheStore after server restart
> ---------------------------------------------------------------------
>
> Key: ISPN-3348
> URL: https://issues.jboss.org/browse/ISPN-3348
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.Alpha1
> Reporter: Martin Gencur
> Assignee: Tristan Tarrant
>
> Using the following configuration:
> {code:xml}
> <subsystem xmlns="urn:infinispan:server:core:5.3" default-cache-container="default">
> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener" eviction-executor="infinispan-eviction" replication-queue-executor="infinispan-repl-queue">
> <local-cache name="default" start="EAGER">
> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/>
> <transaction mode="NONE"/>
> <store class="org.infinispan.loaders.file.SingleFileCacheStore" passivation="false" preload="false" purge="false">
> <property name="location">${java.io.tmpdir}/single-file-cache-store</property>
> <property name="maxEntries">2</property>
> </store>
> </local-cache>
> </cache-container>
> </subsystem>
> {code}
> ...it is not possible to retrieve the cache entry from the cache store after server restart, as demonstrated by the following test:
> {code:java}
> RemoteCache<String, String> rc = rcm.getCache();
> rc.clear();
> assertNull(rc.get("k1"));
> rc.put("k1", "v1");
> rc.put("k2", "v2");
> rc.put("k3", "v3");
> assertEquals("v1", rc.get("k1"));
> assertEquals("v2", rc.get("k2"));
> assertEquals("v3", rc.get("k3"));
> controller.kill(CONTAINER);
> controller.start(CONTAINER);
> assertEquals("v2", rc.get("k2"));
> //^^^fails here - unable to find k2
> assertEquals("v3", rc.get("k3"));
> assertNull(rc.get("k1")); //maxEntries was 2, this entry should be lost as the oldest entries are removed
> controller.stop(CONTAINER);
> {code}
> Note that preload is set to false for this test. When I set it to true, the test passes.
> I tried to modify BaseCacheStoreFunctionalTest#testPreloadAndExpiry, disable "preload" and retrieve the cache entries after server restart by calling cache.get() (not from DataContainer) and the test passed (I ran SingleFileCacheStoreFunctionalTest which extends BaseCacheStoreFunctionalTest). So it seems the bug is related to the server distribution.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3348) Unable to read entries from SingleFileCacheStore after server restart
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3348?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3348:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=986941
> Unable to read entries from SingleFileCacheStore after server restart
> ---------------------------------------------------------------------
>
> Key: ISPN-3348
> URL: https://issues.jboss.org/browse/ISPN-3348
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.Alpha1
> Reporter: Martin Gencur
> Assignee: Tristan Tarrant
>
> Using the following configuration:
> {code:xml}
> <subsystem xmlns="urn:infinispan:server:core:5.3" default-cache-container="default">
> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener" eviction-executor="infinispan-eviction" replication-queue-executor="infinispan-repl-queue">
> <local-cache name="default" start="EAGER">
> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/>
> <transaction mode="NONE"/>
> <store class="org.infinispan.loaders.file.SingleFileCacheStore" passivation="false" preload="false" purge="false">
> <property name="location">${java.io.tmpdir}/single-file-cache-store</property>
> <property name="maxEntries">2</property>
> </store>
> </local-cache>
> </cache-container>
> </subsystem>
> {code}
> ...it is not possible to retrieve the cache entry from the cache store after server restart, as demonstrated by the following test:
> {code:java}
> RemoteCache<String, String> rc = rcm.getCache();
> rc.clear();
> assertNull(rc.get("k1"));
> rc.put("k1", "v1");
> rc.put("k2", "v2");
> rc.put("k3", "v3");
> assertEquals("v1", rc.get("k1"));
> assertEquals("v2", rc.get("k2"));
> assertEquals("v3", rc.get("k3"));
> controller.kill(CONTAINER);
> controller.start(CONTAINER);
> assertEquals("v2", rc.get("k2"));
> //^^^fails here - unable to find k2
> assertEquals("v3", rc.get("k3"));
> assertNull(rc.get("k1")); //maxEntries was 2, this entry should be lost as the oldest entries are removed
> controller.stop(CONTAINER);
> {code}
> Note that preload is set to false for this test. When I set it to true, the test passes.
> I tried to modify BaseCacheStoreFunctionalTest#testPreloadAndExpiry, disable "preload" and retrieve the cache entries after server restart by calling cache.get() (not from DataContainer) and the test passed (I ran SingleFileCacheStoreFunctionalTest which extends BaseCacheStoreFunctionalTest). So it seems the bug is related to the server distribution.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3348) Unable to read entries from SingleFileCacheStore after server restart
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3348?page=com.atlassian.jira.plugin.... ]
Martin Gencur commented on ISPN-3348:
-------------------------------------
I can provide TRACE log if needed, it has ~27 MB though.
> Unable to read entries from SingleFileCacheStore after server restart
> ---------------------------------------------------------------------
>
> Key: ISPN-3348
> URL: https://issues.jboss.org/browse/ISPN-3348
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.Alpha1
> Reporter: Martin Gencur
> Assignee: Tristan Tarrant
>
> Using the following configuration:
> {code:xml}
> <subsystem xmlns="urn:infinispan:server:core:5.3" default-cache-container="default">
> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener" eviction-executor="infinispan-eviction" replication-queue-executor="infinispan-repl-queue">
> <local-cache name="default" start="EAGER">
> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/>
> <transaction mode="NONE"/>
> <store class="org.infinispan.loaders.file.SingleFileCacheStore" passivation="false" preload="false" purge="false">
> <property name="location">${java.io.tmpdir}/single-file-cache-store</property>
> <property name="maxEntries">2</property>
> </store>
> </local-cache>
> </cache-container>
> </subsystem>
> {code}
> ...it is not possible to retrieve the cache entry from the cache store after server restart, as demonstrated by the following test:
> {code:java}
> RemoteCache<String, String> rc = rcm.getCache();
> rc.clear();
> assertNull(rc.get("k1"));
> rc.put("k1", "v1");
> rc.put("k2", "v2");
> rc.put("k3", "v3");
> assertEquals("v1", rc.get("k1"));
> assertEquals("v2", rc.get("k2"));
> assertEquals("v3", rc.get("k3"));
> controller.kill(CONTAINER);
> controller.start(CONTAINER);
> assertEquals("v2", rc.get("k2"));
> //^^^fails here - unable to find k2
> assertEquals("v3", rc.get("k3"));
> assertNull(rc.get("k1")); //maxEntries was 2, this entry should be lost as the oldest entries are removed
> controller.stop(CONTAINER);
> {code}
> Note that preload is set to false for this test. When I set it to true, the test passes.
> I tried to modify BaseCacheStoreFunctionalTest#testPreloadAndExpiry, disable "preload" and retrieve the cache entries after server restart by calling cache.get() (not from DataContainer) and the test passed (I ran SingleFileCacheStoreFunctionalTest which extends BaseCacheStoreFunctionalTest). So it seems the bug is related to the server distribution.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3330) Hotrod clients getWithMetadata doesn't work with dist/repl cache
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3330?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3330:
-----------------------------------
Fix Version/s: 6.0.0.Final
Priority: Minor (was: Major)
> Hotrod clients getWithMetadata doesn't work with dist/repl cache
> ----------------------------------------------------------------
>
> Key: ISPN-3330
> URL: https://issues.jboss.org/browse/ISPN-3330
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.Final
> Reporter: Jakub Markos
> Assignee: Galder Zamarreño
> Priority: Minor
> Fix For: 6.0.0.Final
>
>
> I have a cluster of 2 infinispan servers with this configuration:
> {code:xml}<subsystem xmlns="urn:infinispan:server:core:5.3">
> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener">
> <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/>
> <distributed-cache name="default" start="EAGER" mode="SYNC" segments="1" owners="2" batching="false" l1-lifespan="0" remote-timeout="60000">
> <locking isolation="REPEATABLE_READ"/>
> </distributed-cache>
> </cache-container>
> </subsystem>{code}
> Running this code:
> {code}remoteCache.put("k1", "v1", 10000000, TimeUnit.MICROSECONDS); // setting only lifespan
> MetadataValue<String> k1 = remoteCache.getWithMetadata("k1");
> assertTrue(k1.getValue().equals("v1"));
> // microseconds converted to seconds
> assertTrue(k1.getLifespan() == 10);
> assertTrue(k1.getMaxIdle() == -1);{code}
> fails with:
> {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[5] returned server error (status=0x85): java.lang.ClassCastException: org.infinispan.container.entries.RepeatableReadEntry can
> not be cast to org.infinispan.container.entries.InternalCacheEntry
> 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.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:52)
> at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:35)
> at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:23)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.getWithMetadata(RemoteCacheImpl.java:145){code}
> Works with isolation="READ_COMMITED"/"NONE" or with no <locking> at all.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3348) Unable to read entries from SingleFileCacheStore after server restart
by Martin Gencur (JIRA)
Martin Gencur created ISPN-3348:
-----------------------------------
Summary: Unable to read entries from SingleFileCacheStore after server restart
Key: ISPN-3348
URL: https://issues.jboss.org/browse/ISPN-3348
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 6.0.0.Alpha1
Reporter: Martin Gencur
Assignee: Tristan Tarrant
Using the following configuration:
{code:xml}
<subsystem xmlns="urn:infinispan:server:core:5.3" default-cache-container="default">
<cache-container name="default" default-cache="default" listener-executor="infinispan-listener" eviction-executor="infinispan-eviction" replication-queue-executor="infinispan-repl-queue">
<local-cache name="default" start="EAGER">
<locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/>
<transaction mode="NONE"/>
<store class="org.infinispan.loaders.file.SingleFileCacheStore" passivation="false" preload="false" purge="false">
<property name="location">${java.io.tmpdir}/single-file-cache-store</property>
<property name="maxEntries">2</property>
</store>
</local-cache>
</cache-container>
</subsystem>
{code}
...it is not possible to retrieve the cache entry from the cache store after server restart, as demonstrated by the following test:
{code:java}
RemoteCache<String, String> rc = rcm.getCache();
rc.clear();
assertNull(rc.get("k1"));
rc.put("k1", "v1");
rc.put("k2", "v2");
rc.put("k3", "v3");
assertEquals("v1", rc.get("k1"));
assertEquals("v2", rc.get("k2"));
assertEquals("v3", rc.get("k3"));
controller.kill(CONTAINER);
controller.start(CONTAINER);
assertEquals("v2", rc.get("k2"));
//^^^fails here - unable to find k2
assertEquals("v3", rc.get("k3"));
assertNull(rc.get("k1")); //maxEntries was 2, this entry should be lost as the oldest entries are removed
controller.stop(CONTAINER);
{code}
Note that preload is set to false for this test. When I set it to true, the test passes.
I tried to modify BaseCacheStoreFunctionalTest#testPreloadAndExpiry, disable "preload" and retrieve the cache entries after server restart by calling cache.get() (not from DataContainer) and the test passed (I ran SingleFileCacheStoreFunctionalTest which extends BaseCacheStoreFunctionalTest). So it seems the bug is related to the server distribution.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3330) Hotrod clients getWithMetadata doesn't work with dist/repl cache
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3330?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-3330:
---------------------------------------
[~galderz] yes, we should issue a warning when the hotrod server starts up and finds an "incompatible" cache configuration
> Hotrod clients getWithMetadata doesn't work with dist/repl cache
> ----------------------------------------------------------------
>
> Key: ISPN-3330
> URL: https://issues.jboss.org/browse/ISPN-3330
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.Final
> Reporter: Jakub Markos
> Assignee: Galder Zamarreño
>
> I have a cluster of 2 infinispan servers with this configuration:
> {code:xml}<subsystem xmlns="urn:infinispan:server:core:5.3">
> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener">
> <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/>
> <distributed-cache name="default" start="EAGER" mode="SYNC" segments="1" owners="2" batching="false" l1-lifespan="0" remote-timeout="60000">
> <locking isolation="REPEATABLE_READ"/>
> </distributed-cache>
> </cache-container>
> </subsystem>{code}
> Running this code:
> {code}remoteCache.put("k1", "v1", 10000000, TimeUnit.MICROSECONDS); // setting only lifespan
> MetadataValue<String> k1 = remoteCache.getWithMetadata("k1");
> assertTrue(k1.getValue().equals("v1"));
> // microseconds converted to seconds
> assertTrue(k1.getLifespan() == 10);
> assertTrue(k1.getMaxIdle() == -1);{code}
> fails with:
> {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[5] returned server error (status=0x85): java.lang.ClassCastException: org.infinispan.container.entries.RepeatableReadEntry can
> not be cast to org.infinispan.container.entries.InternalCacheEntry
> 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.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:52)
> at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:35)
> at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:23)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.getWithMetadata(RemoteCacheImpl.java:145){code}
> Works with isolation="READ_COMMITED"/"NONE" or with no <locking> at all.
--
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
11 years, 2 months