[JBoss JIRA] (ISPN-2847) Puts done by state transfer can fail with TimeoutException if lock cannot be acquired
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2847?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2847:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Puts done by state transfer can fail with TimeoutException if lock cannot be acquired
> -------------------------------------------------------------------------------------
>
> Key: ISPN-2847
> URL: https://issues.jboss.org/browse/ISPN-2847
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.2.Final, 5.3.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 5.2.x
> Fix For: 5.2.4.Final, 5.3.0.Final
>
>
> On pessimistic tx caches state transfer can fail for individual keys if they are locked by another tx for too long and timeout expires for the state transfer tx. The error is logged but nothing is done to try to recover the error. The value is lost.
> This can be reproduced easily by running OperationsDuringStateTransferTest configured with pessimistic tx.
--
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, 10 months
[JBoss JIRA] (ISPN-2891) Gap in time between commit of transaction and actual value update
by Jim Crossley (JIRA)
[ https://issues.jboss.org/browse/ISPN-2891?page=com.atlassian.jira.plugin.... ]
Jim Crossley updated ISPN-2891:
-------------------------------
Attachment: pessimistic.log
Just attached another trace (pessimistic.log) showing a similar failure but with pessimistic locking enabled.
> Gap in time between commit of transaction and actual value update
> -----------------------------------------------------------------
>
> Key: ISPN-2891
> URL: https://issues.jboss.org/browse/ISPN-2891
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.2.1.Final
> Reporter: Jim Crossley
> Assignee: Galder Zamarreño
> Labels: 5.2.x
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: bad.log, good.log, pessimistic.log, ugly.log
>
>
> Since upgrading our AS7.2 dependency in Immutant (transitively pulling in 5.2.1.Final), one of our integration tests has begun failing intermittently on our CI server. We've yet to see the failure in local runs, only on CI, so I suspect there's something racist going on.
> The two tests (one for optimistic locking, the other for pessimistic) integrate an Infinispan cache (on which the Immutant cache is built) with HornetQ and XA transactions. A number of queue listeners respond to messages by attempting to increment a value in the cache. The failure occurs with both locking schemes, but much more often with optimistic.
> We've confirmed the failure on 5.2.2 as well.
> Attached you'll find three traces of the optimistic test: the good, the bad, and the ugly. All three correspond to this test: https://github.com/immutant/immutant/blob/31a2ef6222088ccb828898e9e3e4531...
> So you can correlate the log messages prefixed with "JC:" in the traces to the code. Note in particular the last two lines in locking.clj: a logged message containing the count, and then an assertion of the count. Note that the "bad" trace was an actual failing test, but the "ugly" trace was a successful test, even though the trace clearly shows the count logged as 2, not 3. The Infinispan TRACE output clearly shows the value as 3, hence the ugliness of this test.
> It's important to understand that the "work" function occurs within an XA transaction. This means, as I understand it, that if three messages are published to "/queue/done", the cached count should equal 3. Line #44 in locking.clj will block until it receives 3 messages, after which the cached count should be 3.
> These tests always pass locally. They only ever fail on CI, which runs *very* slowly.
--
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, 10 months
[JBoss JIRA] (ISPN-2904) Race condition in cache startup causes state transfer timeout
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-2904?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on ISPN-2904 at 3/8/13 12:41 PM:
-------------------------------------------------------------
I'm pretty sure this bug is a manifestation of https://issues.jboss.org/browse/AS7-5904
The fix is here: https://github.com/jbossas/jboss-as/commit/f2642412dc5ebe34d9cd2221c96ab4...
was (Author: pferraro):
I'm pretty sure this bug is a manifestation of https://issues.jboss.org/browse/AS7-5904
See: https://github.com/jbossas/jboss-as/commit/f2642412dc5ebe34d9cd2221c96ab4...
> Race condition in cache startup causes state transfer timeout
> -------------------------------------------------------------
>
> Key: ISPN-2904
> URL: https://issues.jboss.org/browse/ISPN-2904
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.1.7.Final
> Reporter: Dennis Reed
> Assignee: Mircea Markus
>
> When starting multiple caches at the same time (as EAP domain mode deployment does), one cache can timeout during state transfer and abort startup.
> This is caused by a race condition where the master node accepts requests while it can't process them because it's still starting.
> Because of this, the other node's REQUEST_JOIN is ignored, and it finally times out.
> [node1]
> 10:47:23,390 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 65) dests=[master:server-two/web], command=CacheViewControlCommand{cache=repl, type=REQUEST_JOIN, sender=master:server-one/web, newViewId=0, newMembers=null, oldViewId=0, oldMembers=null}, mode=SYNCHRONOUS_IGNORE_LEAVERS, timeout=60000
> 10:47:23,396 TRACE [org.jgroups.protocols.TCP] (ServerService Thread Pool -- 65) sending msg to master:server-two/web, src=master:server-one/web, headers are RequestCorrelator: id=200, type=REQ, id=7, rsp_expected=true, RSVP: REQ(4), UNICAST2: DATA, seqno=27, TCP: [channel_name=web]
> ...
> 10:48:23,404 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) MSC000001: Failed to start service jboss.infinispan.web.repl: org.jboss.msc.service.StartException in service jboss.infinispan.web.repl: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.BaseStateTransferManagerImpl.waitForJoinToComplete() throws java.lang.InterruptedException on object of type ReplicatedStateTransferManagerImpl
> [node2]
> 10:47:23,352 TRACE [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-6) Registering component Component{instance=org.infinispan.marshall.jboss.ExternalizerTable@3f9c437d, name=org.infinispan.marshall.jboss.ExternalizerTable} under name org.infinispan.marshall.jboss.ExternalizerTable
> ...
> 10:47:23,397 TRACE [org.jgroups.protocols.TCP] (OOB-19,null) received [dst: master:server-two/web, src: master:server-one/web (4 headers), size=54 bytes, flags=OOB|DONT_BUNDLE|RSVP], headers are RequestCorrelator: id=200, type=REQ, id=7, rsp_expected=true, RSVP: REQ(4), UNICAST2: DATA, seqno=27, TCP: [channel_name=web]
> 10:47:23,398 TRACE [org.jgroups.blocks.RequestCorrelator] (OOB-19,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 7
> 10:47:23,398 TRACE [org.infinispan.marshall.jboss.ExternalizerTable] (OOB-19,null) Either the marshaller has stopped or hasn't started. Read externalizers are not properly populated: {}
> 10:47:23,398 TRACE [org.infinispan.marshall.jboss.ExternalizerTable] (OOB-19,null) Cache manager is shutting down and type (id=74) cannot be resolved (thread not interrupted)
> 10:47:23,400 TRACE [org.jgroups.blocks.RequestCorrelator] (OOB-19,null) sending rsp for 7 to master:server-one/web
> ...
> 10:47:23,522 TRACE [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 64) Invoking start method public void org.infinispan.marshall.jboss.ExternalizerTable.start() on component org.infinispan.marshall.jboss.ExternalizerTable
--
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, 10 months
[JBoss JIRA] (ISPN-2904) Race condition in cache startup causes state transfer timeout
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-2904?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on ISPN-2904:
------------------------------------
I'm pretty sure this bug is a manifestation of https://issues.jboss.org/browse/AS7-5904
See: https://github.com/jbossas/jboss-as/commit/f2642412dc5ebe34d9cd2221c96ab4...
> Race condition in cache startup causes state transfer timeout
> -------------------------------------------------------------
>
> Key: ISPN-2904
> URL: https://issues.jboss.org/browse/ISPN-2904
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.1.7.Final
> Reporter: Dennis Reed
> Assignee: Mircea Markus
>
> When starting multiple caches at the same time (as EAP domain mode deployment does), one cache can timeout during state transfer and abort startup.
> This is caused by a race condition where the master node accepts requests while it can't process them because it's still starting.
> Because of this, the other node's REQUEST_JOIN is ignored, and it finally times out.
> [node1]
> 10:47:23,390 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 65) dests=[master:server-two/web], command=CacheViewControlCommand{cache=repl, type=REQUEST_JOIN, sender=master:server-one/web, newViewId=0, newMembers=null, oldViewId=0, oldMembers=null}, mode=SYNCHRONOUS_IGNORE_LEAVERS, timeout=60000
> 10:47:23,396 TRACE [org.jgroups.protocols.TCP] (ServerService Thread Pool -- 65) sending msg to master:server-two/web, src=master:server-one/web, headers are RequestCorrelator: id=200, type=REQ, id=7, rsp_expected=true, RSVP: REQ(4), UNICAST2: DATA, seqno=27, TCP: [channel_name=web]
> ...
> 10:48:23,404 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) MSC000001: Failed to start service jboss.infinispan.web.repl: org.jboss.msc.service.StartException in service jboss.infinispan.web.repl: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.BaseStateTransferManagerImpl.waitForJoinToComplete() throws java.lang.InterruptedException on object of type ReplicatedStateTransferManagerImpl
> [node2]
> 10:47:23,352 TRACE [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-6) Registering component Component{instance=org.infinispan.marshall.jboss.ExternalizerTable@3f9c437d, name=org.infinispan.marshall.jboss.ExternalizerTable} under name org.infinispan.marshall.jboss.ExternalizerTable
> ...
> 10:47:23,397 TRACE [org.jgroups.protocols.TCP] (OOB-19,null) received [dst: master:server-two/web, src: master:server-one/web (4 headers), size=54 bytes, flags=OOB|DONT_BUNDLE|RSVP], headers are RequestCorrelator: id=200, type=REQ, id=7, rsp_expected=true, RSVP: REQ(4), UNICAST2: DATA, seqno=27, TCP: [channel_name=web]
> 10:47:23,398 TRACE [org.jgroups.blocks.RequestCorrelator] (OOB-19,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 7
> 10:47:23,398 TRACE [org.infinispan.marshall.jboss.ExternalizerTable] (OOB-19,null) Either the marshaller has stopped or hasn't started. Read externalizers are not properly populated: {}
> 10:47:23,398 TRACE [org.infinispan.marshall.jboss.ExternalizerTable] (OOB-19,null) Cache manager is shutting down and type (id=74) cannot be resolved (thread not interrupted)
> 10:47:23,400 TRACE [org.jgroups.blocks.RequestCorrelator] (OOB-19,null) sending rsp for 7 to master:server-one/web
> ...
> 10:47:23,522 TRACE [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 64) Invoking start method public void org.infinispan.marshall.jboss.ExternalizerTable.start() on component org.infinispan.marshall.jboss.ExternalizerTable
--
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, 10 months
[JBoss JIRA] (ISPN-2847) Puts done by state transfer can fail with TimeoutException if lock cannot be acquired
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2847?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2847:
-------------------------------------
By examining the origin of this issue I concluded it can happen on any TX cache, no matter if it's pessimistic or optimistic.
> Puts done by state transfer can fail with TimeoutException if lock cannot be acquired
> -------------------------------------------------------------------------------------
>
> Key: ISPN-2847
> URL: https://issues.jboss.org/browse/ISPN-2847
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.2.Final, 5.3.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 5.2.x
> Fix For: 5.2.4.Final, 5.3.0.Final
>
>
> On pessimistic tx caches state transfer can fail for individual keys if they are locked by another tx for too long and timeout expires for the state transfer tx. The error is logged but nothing is done to try to recover the error. The value is lost.
> This can be reproduced easily by running OperationsDuringStateTransferTest configured with pessimistic tx.
--
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, 10 months
[JBoss JIRA] (ISPN-2847) Puts done by state transfer can fail with TimeoutException if lock cannot be acquired
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2847?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2847:
----------------------------------
Fix Version/s: 5.2.4.Final
> Puts done by state transfer can fail with TimeoutException if lock cannot be acquired
> -------------------------------------------------------------------------------------
>
> Key: ISPN-2847
> URL: https://issues.jboss.org/browse/ISPN-2847
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.2.Final, 5.3.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 5.2.x
> Fix For: 5.2.4.Final, 5.3.0.Final
>
>
> On pessimistic tx caches state transfer can fail for individual keys if they are locked by another tx for too long and timeout expires for the state transfer tx. The error is logged but nothing is done to try to recover the error. The value is lost.
> This can be reproduced easily by running OperationsDuringStateTransferTest configured with pessimistic tx.
--
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, 10 months
[JBoss JIRA] (ISPN-2847) Puts done by state transfer can fail with TimeoutException if lock cannot be acquired
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2847?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2847:
-------------------------------------
Stacktrace from test.
{noformat}
2013-03-08 18:12:10,715 ERROR [InvocationContextInterceptor] (OOB-1,ISPN,NodeB-7053) ISPN000136: Execution error
org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on myKey on behalf of transaction GlobalTransaction:<NodeB-7053>:3:local. Lock is being held by null
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.newTimeoutException(AbstractTxLockingInterceptor.java:218)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.waitForTransactionsToComplete(AbstractTxLockingInterceptor.java:211)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:172)
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPutKeyValueCommand(PessimisticLockingInterceptor.java:122)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:255)
at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:191)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:211)
at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:194)
at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:136)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
at org.infinispan.statetransfer.StateConsumerImpl.doApplyState(StateConsumerImpl.java:481)
at org.infinispan.statetransfer.StateConsumerImpl.applyState(StateConsumerImpl.java:432)
at org.infinispan.statetransfer.StateResponseCommand.perform(StateResponseCommand.java:86)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:101)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:122)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:86)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:247)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:220)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:472)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:377)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:664)
at org.jgroups.JChannel.up(JChannel.java:719)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1007)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:178)
at org.jgroups.protocols.FC.up(FC.java:467)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:237)
at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:791)
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:411)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:609)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
at org.jgroups.protocols.Discovery.up(Discovery.java:371)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1267)
at org.jgroups.protocols.TP$MyHandler.run(TP.java:1398)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{noformat}
> Puts done by state transfer can fail with TimeoutException if lock cannot be acquired
> -------------------------------------------------------------------------------------
>
> Key: ISPN-2847
> URL: https://issues.jboss.org/browse/ISPN-2847
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.2.Final, 5.3.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 5.2.x
> Fix For: 5.3.0.Final
>
>
> On pessimistic tx caches state transfer can fail for individual keys if they are locked by another tx for too long and timeout expires for the state transfer tx. The error is logged but nothing is done to try to recover the error. The value is lost.
> This can be reproduced easily by running OperationsDuringStateTransferTest configured with pessimistic tx.
--
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, 10 months
[JBoss JIRA] (ISPN-2903) CLONE - Eviction causes lost AtomicMap entries
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2903:
----------------------------------
Fix Version/s: 5.2.5.Final
(was: 5.2.4.Final)
> CLONE - Eviction causes lost AtomicMap entries
> ----------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: jdg6
> Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
--
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, 10 months