[ https://issues.jboss.org/browse/ISPN-3780?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3780: ------------------------------------- Radim, do you happen to have a link to the entire trace? In the cases I am finding the put is retried properly with the new topology and everything is fine. I have tried a few slight variations of the following case you originally stated. {quote} 1. D executes PUT -> sends command to A 2. A executes the PUT, sends invalidation to C 3. ST from A to C begins 4. C receives InvalidateL1 and puts this key into updateKeys 5. C receives state but ignores the updated key {quote} In this case the put on A should end up throwing a OutdatedTopologyException after it tries to commit which would cause a retry to occur from node D with the updated topology which would put the correct value into C. I wonder though if the L1 invalidation came from the L1LastChanceInterceptor though as that would not cause a retry. It could be that the commit completes, then the topology is updated and then last chance fires, which is why it would have the correct topology id on the command. I will try to get that test up and running. The complete log would help show me if that matches your case or not. Either way I wouldn't expect the value to be in L1 still. I would expect the value to be removed from the invalidation, can you confirm if that is true? Looking at the log it looks like it was already null "Entry for key key_0000000000003154 is null" -- 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