[
https://issues.jboss.org/browse/ISPN-3780?page=com.atlassian.jira.plugin....
]
William Burns edited comment on ISPN-3780 at 12/5/13 4:06 PM:
--------------------------------------------------------------
{quote}The topology change is started on A only after the invalidation has been sent to
C.{quote}
Yeah it appears that the new topology was only installed on C before the invalidation
arrived and A doesn't get the new topology until after the put command is completed
which is why it wasn't retried.
Now normally I would think the topology check in the entryCommit in
EntryWrappingInterceptor would then throw an error since A topolyg is 1 behind, however
the topologyId is always -1 for InvalidateL1Commands. It is never set in
StateTransferInterceptor and the setting of the topology doesn't work in RpcMangerImpl
because the command is wrapped in a CacheRpcCommand which doesn't implement
TopologyAffectedCommand. I think the easiest fix is to move the if check higher up in
RpcManagerImpl, but I will get a test going first to confirm this. Also I will try to fix
the issue I found with the LastChanceInterceptor which this may also fix.
was (Author: william.burns):
{quote}The topology change is started on A only after the invalidation has been sent
to C.{quote}
Yeah it appears that the new topology was only installed on C before the invalidation
arrived and A doesn't get the new topology until after the put command is completed.
Now normally I would think the topology check in the entryCommit in
EntryWrappingInterceptor would then throw an error. However the topologyId is always a -1
for InvalidateL1Commands. It is never set in StateTransferInterceptor and the setting of
the topology doesn't work in RpcMangerImpl because the command is wrapped in a
CacheRpcCommand which doesn't implement TopologyAffectedCommand. I think the easiest
fix is to move the if check higher up in RpcManagerImpl, but I will get a test going first
to confirm this. Also I will try to fix the issue I found with the LastChanceInterceptor
which this may also fix.
CLONE - InvalidateL1Command during ST should not cancel writing the
entry by ST in nontx
----------------------------------------------------------------------------------------
Key: ISPN-3780
URL:
https://issues.jboss.org/browse/ISPN-3780
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Affects Versions: 5.3.0.Final
Reporter: Radim Vansa
Assignee: William Burns
Priority: Critical
Labels: 620
Fix For: 6.1.0.Final
When a node which is about to receive the entries for some segment receives
InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries
for ST are received, the entry which was invalidated is not updated -> this result in
losing the entry.
Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up
entries for each entry - this causes some performance problems when tracing is on and
there are many invalidated entries. Please, do this only once.
--
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