[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 commented on ISPN-5459:
-----------------------------------------------
Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1255665|https://bugzilla.redhat.com/show_bug.cgi?id=1255665] from NEW to POST
> 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, 2 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 commented on ISPN-5459:
-----------------------------------------------
Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1259418|https://bugzilla.redhat.com/show_bug.cgi?id=1259418] from NEW to ASSIGNED
> 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, 2 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 References: https://bugzilla.redhat.com/show_bug.cgi?id=1255665, https://bugzilla.redhat.com/show_bug.cgi?id=1259418 (was: 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, 2 months
[JBoss JIRA] (ISPN-5691) Server should enable writeSkew for some configurations by default
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5691?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-5691:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1255783, https://bugzilla.redhat.com/show_bug.cgi?id=1259355 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1255783)
> Server should enable writeSkew for some configurations by default
> -----------------------------------------------------------------
>
> Key: ISPN-5691
> URL: https://issues.jboss.org/browse/ISPN-5691
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Reporter: Galder Zamarreño
> Assignee: Tristan Tarrant
> Fix For: 7.2.5.Final, 8.1.0.Final
>
>
> By default, optimistic locking caches do not enable write skew. This was already spotted in ISPN-3655.
> In an embedded environment, the user can always enable write skew in its configuration, but this cannot be enabled in server mode.
> Widlfly does enable write skew programmatically depending on the configuration:
> {quote}
> > hey, quick q: can you configure writeSkew on infinispan wildfly
> config?
> <pferraro> we always enable write skew for synchronous, optimistic,
> repeatable-read caches, and disable otherwise
> > pferraro: ah, you do it in the integration code?
> <pferraro> yes
> {quote}
> We need to be doing the same in server configuration, otherwise we run the risk of having issues with conditional operations under failure situations (see ISPN-2956)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ISPN-5691) Server should enable writeSkew for some configurations by default
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5691?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5691:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1259355|https://bugzilla.redhat.com/show_bug.cgi?id=1259355] from NEW to POST
> Server should enable writeSkew for some configurations by default
> -----------------------------------------------------------------
>
> Key: ISPN-5691
> URL: https://issues.jboss.org/browse/ISPN-5691
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Reporter: Galder Zamarreño
> Assignee: Tristan Tarrant
> Fix For: 7.2.5.Final, 8.1.0.Final
>
>
> By default, optimistic locking caches do not enable write skew. This was already spotted in ISPN-3655.
> In an embedded environment, the user can always enable write skew in its configuration, but this cannot be enabled in server mode.
> Widlfly does enable write skew programmatically depending on the configuration:
> {quote}
> > hey, quick q: can you configure writeSkew on infinispan wildfly
> config?
> <pferraro> we always enable write skew for synchronous, optimistic,
> repeatable-read caches, and disable otherwise
> > pferraro: ah, you do it in the integration code?
> <pferraro> yes
> {quote}
> We need to be doing the same in server configuration, otherwise we run the risk of having issues with conditional operations under failure situations (see ISPN-2956)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ISPN-5691) Server should enable writeSkew for some configurations by default
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5691?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5691:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1255783|https://bugzilla.redhat.com/show_bug.cgi?id=1255783] from NEW to POST
> Server should enable writeSkew for some configurations by default
> -----------------------------------------------------------------
>
> Key: ISPN-5691
> URL: https://issues.jboss.org/browse/ISPN-5691
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Reporter: Galder Zamarreño
> Assignee: Tristan Tarrant
> Fix For: 7.2.5.Final, 8.1.0.Final
>
>
> By default, optimistic locking caches do not enable write skew. This was already spotted in ISPN-3655.
> In an embedded environment, the user can always enable write skew in its configuration, but this cannot be enabled in server mode.
> Widlfly does enable write skew programmatically depending on the configuration:
> {quote}
> > hey, quick q: can you configure writeSkew on infinispan wildfly
> config?
> <pferraro> we always enable write skew for synchronous, optimistic,
> repeatable-read caches, and disable otherwise
> > pferraro: ah, you do it in the integration code?
> <pferraro> yes
> {quote}
> We need to be doing the same in server configuration, otherwise we run the risk of having issues with conditional operations under failure situations (see ISPN-2956)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ISPN-5677) HR putIfAbsentAsync not enforcing withFlags(Flag.FORCE_RETURN_VALUE)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5677?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5677:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1252986|https://bugzilla.redhat.com/show_bug.cgi?id=1252986] from NEW to POST
> HR putIfAbsentAsync not enforcing withFlags(Flag.FORCE_RETURN_VALUE)
> ----------------------------------------------------------------------
>
> Key: ISPN-5677
> URL: https://issues.jboss.org/browse/ISPN-5677
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.2.Final
> Reporter: Shay Matasaro
> Assignee: Gustavo Fernandes
> Fix For: 8.0.0.CR1, 8.0.0.Final, 7.2.5.Final
>
>
> given the following HR client code
> NotifyingFuture<String> f1 = cache.withFlags(Flag.FORCE_RETURN_VALUE).putIfAbsentAsync(key, "1");
> System.out.println(f1.get(10,TimeUnit.MINUTES));
> NotifyingFuture<String> f2 = cache.withFlags(Flag.FORCE_RETURN_VALUE).putIfAbsentAsync(key, "2");
> System.out.println(f2.get(10,TimeUnit.MINUTES));
> both prints print null, where the second one should print "1"
> only when props.put("infinispan.client.hotrod.force_return_values","true") is set specifically when building the CM then the calls work
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ISPN-5720) putForExternalRead may not acquire lock in invalidation mode
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-5720?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-5720:
-----------------------------------
The more I think about this, invalidation mode should always acquire locks, there the notion of primary owner does not make sense since we just broadcast the invalidation, not going to primary first.
> putForExternalRead may not acquire lock in invalidation mode
> ------------------------------------------------------------
>
> Key: ISPN-5720
> URL: https://issues.jboss.org/browse/ISPN-5720
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.0.0.Final
> Reporter: Radim Vansa
>
> Usual PutKeyValueCommands go to primary owner to acquire the lock, and then they can safely modify the entry on backup owners.
> In invalidation mode, the puts are not distributed (there's no xDistributionInterceptor) and InvalidationInterceptor has special switch for PFER that lets it through. That way, when the PFER is executed on non-primary node, it gets executed without lock being held, potentially overwriting another operation.
> The same issue is with all write commands that get invoked with LOCAL_MODE flag. Fixing this is troublesome, since we don't want to lock keys on backup owners too (that would not cause deadlock if done *after* acquiring lock on primary, but it would incur performance hit). However, for PFER specifically we could use putIfAbsent operation on datacontainer during entry commit (this was [~dan.berindei]'s idea).
> This could be even generalized to do a compute() check on the container, verifying equality of stored vs. wrapped value, but I am not sure about the consequences.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (ISPN-5720) putForExternalRead may not acquire lock in invalidation mode
by Radim Vansa (JIRA)
Radim Vansa created ISPN-5720:
---------------------------------
Summary: putForExternalRead may not acquire lock in invalidation mode
Key: ISPN-5720
URL: https://issues.jboss.org/browse/ISPN-5720
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.0.0.Final
Reporter: Radim Vansa
Usual PutKeyValueCommands go to primary owner to acquire the lock, and then they can safely modify the entry on backup owners.
In invalidation mode, the puts are not distributed (there's no xDistributionInterceptor) and InvalidationInterceptor has special switch for PFER that lets it through. That way, when the PFER is executed on non-primary node, it gets executed without lock being held, potentially overwriting another operation.
The same issue is with all write commands that get invoked with LOCAL_MODE flag. Fixing this is troublesome, since we don't want to lock keys on backup owners too (that would not cause deadlock if done *after* acquiring lock on primary, but it would incur performance hit). However, for PFER specifically we could use putIfAbsent operation on datacontainer during entry commit (this was [~dan.berindei]'s idea).
This could be even generalized to do a compute() check on the container, verifying equality of stored vs. wrapped value, but I am not sure about the consequences.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months