[
https://issues.redhat.com/browse/ISPN-12518?page=com.atlassian.jira.plugi...
]
Will Burns commented on ISPN-12518:
-----------------------------------
Looking into this more closely it appears to be the following issue:
replace is fired on key 1 - the primary owner does not see it expired and sends a backup
request later. The backup then applies the replace command but sees the entry expired so
it attempts to remove the expired value. The problem is then the primary performs the
remove expired but it cannot be processed on the backup as the prior command has yet to
complete due to ordering in BlockingTaskAwareExecutorImpl.
The simplest fix is probably not to check expiration from a backup command just apply it
as is as the primary would have already notified other nodes of the changed value
anyways.
Possible deadlock if an entry is replaced at the same time expiration
take effect
---------------------------------------------------------------------------------
Key: ISPN-12518
URL:
https://issues.redhat.com/browse/ISPN-12518
Project: Infinispan
Issue Type: Bug
Affects Versions: 12.0.0.Dev06
Reporter: Wolf-Dieter Fink
Assignee: Will Burns
Priority: Major
Attachments: reproducer.zip
When replacing a value for key, close to the keys expiration time, Infinispan can lock
itself where both nodes are waiting for each other, resulting in ISPN000427, instead of
the command completing with success (expected) or failure (not expected because it should
be replaced)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)