[JBoss JIRA] (ISPN-11079) Cluster Expiration and Optimistic Transactions write skew issues
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11079?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11079:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Cluster Expiration and Optimistic Transactions write skew issues
> ----------------------------------------------------------------
>
> Key: ISPN-11079
> URL: https://issues.redhat.com/browse/ISPN-11079
> Project: Infinispan
> Issue Type: Bug
> Components: Expiration
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.1.0.Final, 11.0.0.Final
>
>
> Optimistic write skew and clustered expiration can have some weird issues
> One such is:
> The issue is the following:
> 1. RemoveExpiredCommand reads the expired from the container with version 1 and puts in its context
> 2. PutKeyValueCommand sees nothing in container due to expired and adds a new entry with version 1 in its context
> 3. Put gets the lock and replaces the value
> 4. RemoveExpiredCommand attempts to run and because it saw the old value the lifespans still match (if different)
> 5. Then the write skew passes for the remove expired command since the value in container and its context both have version 1
> To workaround this for now we should prevent a get of an expired entry from returning early when using optimistic transactions.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (ISPN-11049) Infinispan Server should resolve all the console URLs
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11049?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11049:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 10.1.0.Final
Resolution: Done
> Infinispan Server should resolve all the console URLs
> -----------------------------------------------------
>
> Key: ISPN-11049
> URL: https://issues.redhat.com/browse/ISPN-11049
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.1.0.Beta1
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Priority: Major
> Fix For: 10.1.0.Final
>
>
> Infinispan server serves the console from the static resources. This console is an front end app built in react that contains multiple URL paths.
> When we do F5 on a URL that is not 'console' or 'console/wlecome' the server responds with 404.
> The static resource (or console resource) should be able to serve the console app from any of the '/console/*' Urls so there is no 404 when there ir s refresh
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (ISPN-11102) Purge on JDBC shared stores can cause deadlocks
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-11102:
-----------------------------------
Summary: Purge on JDBC shared stores can cause deadlocks
Key: ISPN-11102
URL: https://issues.redhat.com/browse/ISPN-11102
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 9.4.17.Final, 10.1.0.CR1
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 10.1.0.Final, 9.4.18.Final
ISPN-10337 ensured that the JdbcStringBasedStore correctly acquired the locks of expired rows during the purging of store entries, however it has exposed an issue with shared stores. When the jdbc store is shared, the coordinator locks the rows of the affected entries and releases them once they have all been removed as part of the purge transaction. However, the call to {{ExpirationManager::handleInStoreExpiration}} also sends a {{RemoveExpiredCommand}} to ensure that entries are removed from memory. This results in a {{java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction}} being thrown by the store's delete method when the purge process is still in progress, because the expired rows are still locked and the purge process cannot complete until the {{RemoveExpiredCommand}} has been executed.
In summary:
# purge locks all the rows
# purge sends a RemoveExpiredCommand and waits for it to complete
# RemoveExpiredCommand tries to remove the row but it can't as it is locked
Solution, send the {{RemoveExpiredCommand}} with the {{SKIP_CACHE_STORE}} flag when a store is shared,so that it only removes entries from memory.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (ISPN-11101) Purge on JDBC shared stores can cause deadlocks
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-11101:
-----------------------------------
Summary: Purge on JDBC shared stores can cause deadlocks
Key: ISPN-11101
URL: https://issues.redhat.com/browse/ISPN-11101
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 10.1.0.CR1, 9.4.17.Final
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 10.1.0.Final, 9.4.18.Final
ISPN-10337 ensured that the JdbcStringBasedStore correctly acquired the locks of expired rows during the purging of store entries, however it has exposed an issue with shared stores. When the jdbc store is shared, the coordinator locks the rows of the affected entries and releases them once they have all been removed as part of the purge transaction. However, the call to {{ExpirationManager::handleInStoreExpiration}} also sends a {{RemoveExpiredCommand}} to ensure that entries are removed from memory. This results in a {{java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction}} being thrown by the store's delete method when the purge process is still in progress, because the expired rows are still locked and the purge process cannot complete until the {{RemoveExpiredCommand}} has been executed.
In summary:
# purge locks all the rows
# purge sends a RemoveExpiredCommand and waits for it to complete
# RemoveExpiredCommand tries to remove the row but it can't as it is locked
Solution, send the {{RemoveExpiredCommand}} with the {{SKIP_CACHE_STORE}} flag when a store is shared,so that it only removes entries from memory.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months