[JBoss JIRA] (ISPN-5664) Null is returned for a not expired entry in Hot Rod client
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5664?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-5664:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Null is returned for a not expired entry in Hot Rod client
> ----------------------------------------------------------
>
> Key: ISPN-5664
> URL: https://issues.jboss.org/browse/ISPN-5664
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 8.0.0.Beta2
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 8.0.0.CR1, 7.2.5.Final
>
>
> For a mortal entry (lifespan > -1), overwriting it with lifespan=-1 (make it immortal) unexpectedly removes the entry like follows.
> ~~~
> cache.put(key, "value1", 100, TimeUnit.SECONDS, 100, TimeUnit.SECONDS);
> cache.get(key); // returns "value1"
> cache.put(key, "value2", -1, TimeUnit.SECONDS, 100, TimeUnit.SECONDS);
> cache.get(key); // returns null, expected "value2"
> cache.put(key, "value3", -1, TimeUnit.SECONDS, 100, TimeUnit.SECONDS);
> cache.get(key); // returns "value3"
> ~~~
> In library mode, the 2nd get returns non-null as expected. The same behaviour is observed for a transient (maxIdle > -1) entry also.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (ISPN-5670) Hot Rod server sets -1 for lifespan or maxIdle as default
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5670?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-5670:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Hot Rod server sets -1 for lifespan or maxIdle as default
> ---------------------------------------------------------
>
> Key: ISPN-5670
> URL: https://issues.jboss.org/browse/ISPN-5670
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 8.0.0.CR1, 7.2.5.Final
>
>
> The hotrod server currently keeps the default lifespan and maxIdle in the CacheDecodeContext. This works fine however a metadata is generated ignoring that if -1 is passed. Instead the put(K, V, Metadata) merges the default metadata into the one generated, which won't have a lifespan or maxIdle set since it was -1. In this case the merge method will take the default value instead. We should explicitly set the metadata to -1 before calling put(K, V, Metadata)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (ISPN-5607) NearCache: it is possible to read stale data with a put/remove followed by a get
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5607?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-5607:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> NearCache: it is possible to read stale data with a put/remove followed by a get
> --------------------------------------------------------------------------------
>
> Key: ISPN-5607
> URL: https://issues.jboss.org/browse/ISPN-5607
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.2.3.Final
> Environment: one hotrod client with 2 hotrod servers
> Reporter: Enrico Olivelli
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 8.0.0.CR1, 8.0.0.Final, 7.2.5.Final
>
>
> Writes to the NearCache do not invalidate/update local data on put/remove operations, and so the NearCache (LAZY MODE) is invalidated using an eventlistener in an asynch way.
> It is possible for a client to write a value and issue a get on the same key, and the result of the get would not be the latest value but the one which was present before the update operation.
> This happens frequently when there is very much traffic on the connection of the listener which receives the events for the NearCache.
> It would be better at least to invalidate locally every entry modified from the client itself
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (ISPN-5607) NearCache: it is possible to read stale data with a put/remove followed by a get
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5607?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-5607:
------------------------------------
Fix Version/s: 8.0.0.CR1
> NearCache: it is possible to read stale data with a put/remove followed by a get
> --------------------------------------------------------------------------------
>
> Key: ISPN-5607
> URL: https://issues.jboss.org/browse/ISPN-5607
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.2.3.Final
> Environment: one hotrod client with 2 hotrod servers
> Reporter: Enrico Olivelli
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 8.0.0.CR1, 8.0.0.Final, 7.2.5.Final
>
>
> Writes to the NearCache do not invalidate/update local data on put/remove operations, and so the NearCache (LAZY MODE) is invalidated using an eventlistener in an asynch way.
> It is possible for a client to write a value and issue a get on the same key, and the result of the get would not be the latest value but the one which was present before the update operation.
> This happens frequently when there is very much traffic on the connection of the listener which receives the events for the NearCache.
> It would be better at least to invalidate locally every entry modified from the client itself
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months
[JBoss JIRA] (ISPN-5459) StateTransferManager.waitForInitialTransferToComplete can fail if the coordinator crashes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5459?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-5459:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1255665
> StateTransferManager.waitForInitialTransferToComplete can fail if the coordinator crashes
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-5459
> URL: https://issues.jboss.org/browse/ISPN-5459
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.2.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 8.0.0.Alpha2
>
>
> {{LocalTopologyManagerImpl.isRebalancingEnabled()}} will throw a {{SuspectException}} if the coordinator crashes, preventing the cache from starting up.
> This is causing random failures in {{ClusterListenerDistTxAddListenerTest}}:
> {noformat}
> 22:23:59,439 ERROR (testng-ClusterListenerDistTxAddListenerTest:) [UnitTestTestNGListener] Test testNodeJoiningAndStateNodeDiesWithExistingClusterListener(org.infinispan.notifications.cachelistener.cluster.ClusterListenerDistTxAddListenerTest) failed.
> java.util.concurrent.ExecutionException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:202)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerDistAddListenerTest.testNodeJoiningAndStateNodeDiesWithExistingClusterListener(AbstractClusterListenerDistAddListenerTest.java:254)
> ...
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:850)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:599)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:554)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:424)
> at org.infinispan.test.MultipleCacheManagersTest.cache(MultipleCacheManagersTest.java:366)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerDistAddListenerTest.access$100(AbstractClusterListenerDistAddListenerTest.java:32)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerDistAddListenerTest$4.call(AbstractClusterListenerDistAddListenerTest.java:237)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerDistAddListenerTest$4.call(AbstractClusterListenerDistAddListenerTest.java:234)
> at org.infinispan.test.AbstractInfinispanTest$LoggingCallable.call(AbstractInfinispanTest.java:422)
> ... 4 more
> Caused by: org.infinispan.remoting.transport.jgroups.SuspectException: Node NodeM-34961 was suspected
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:245)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:566)
> at org.infinispan.topology.LocalTopologyManagerImpl.executeOnCoordinator(LocalTopologyManagerImpl.java:501)
> at org.infinispan.topology.LocalTopologyManagerImpl.isRebalancingEnabled(LocalTopologyManagerImpl.java:445)
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:216)
> at sun.reflect.GeneratedMethodAccessor165.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 18 more
> Caused by: SuspectedException
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:414)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:427)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:240)
> ... 26 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 7 months