[JBoss JIRA] (ISPN-6745) Locks are lost in pessimistic cache
by Eugene Scripnik (JIRA)
[ https://issues.jboss.org/browse/ISPN-6745?page=com.atlassian.jira.plugin.... ]
Eugene Scripnik updated ISPN-6745:
----------------------------------
Description:
When you perform multiple TX write operations in one transaction (put, replace, lock, etc) and one of the nodes goes down, there is a slight chance that some locks will be lost and acquired by another transaction before current transaction ends.
So client ends up with two transactions holding the same lock on pessimistic cache at the same time. Both transactions commit at the end successfully.
I spent some time debugging infinispan code and found that PessimisticLockingInterceptor#releaseLocksOnFailureBeforePrepare releases all locks when OutdatedTopologyException occurs on remote node. But then StateTransferInterceptor#handleTxWriteCommand retries last command. This behavior produces inconsistent state - all locks before last command are released and any other transaction can acquire them.
I am attaching Test which reproduces this problem
was:
When you perform multiple TX write operations in one transaction (put, replace, lock, etc) and one of the nodes goes down, there is a slight chance that some locks will be lost and acquired by another transaction.
So client ends up with two transactions holding the same lock on pessimistic cache at the same time. Both transactions commit at the end successfully.
I spent some time debugging infinispan code and found that PessimisticLockingInterceptor#releaseLocksOnFailureBeforePrepare releases all locks when OutdatedTopologyException occurs on remote node. But then StateTransferInterceptor#handleTxWriteCommand retries last command. This behavior produces inconsistent state - all locks before last command are released and any other transaction can acquire them.
I am attaching Test which reproduces this problem
> Locks are lost in pessimistic cache
> -----------------------------------
>
> Key: ISPN-6745
> URL: https://issues.jboss.org/browse/ISPN-6745
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.2.3.Final
> Environment: JBoss DataGrid 6.5.0 (6.3.1.Final-redhat-1)
> 3 nodes in REPL_SYNC mode
> pessimistic locking
> read committed isolation
> Reporter: Eugene Scripnik
> Attachments: InfinispanNodeFailureTest.java
>
>
> When you perform multiple TX write operations in one transaction (put, replace, lock, etc) and one of the nodes goes down, there is a slight chance that some locks will be lost and acquired by another transaction before current transaction ends.
> So client ends up with two transactions holding the same lock on pessimistic cache at the same time. Both transactions commit at the end successfully.
> I spent some time debugging infinispan code and found that PessimisticLockingInterceptor#releaseLocksOnFailureBeforePrepare releases all locks when OutdatedTopologyException occurs on remote node. But then StateTransferInterceptor#handleTxWriteCommand retries last command. This behavior produces inconsistent state - all locks before last command are released and any other transaction can acquire them.
> I am attaching Test which reproduces this problem
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-6745) Locks are lost in pessimistic cache
by Eugene Scripnik (JIRA)
Eugene Scripnik created ISPN-6745:
-------------------------------------
Summary: Locks are lost in pessimistic cache
Key: ISPN-6745
URL: https://issues.jboss.org/browse/ISPN-6745
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 7.2.3.Final
Environment: JBoss DataGrid 6.5.0 (6.3.1.Final-redhat-1)
3 nodes in REPL_SYNC mode
pessimistic locking
read committed isolation
Reporter: Eugene Scripnik
Attachments: InfinispanNodeFailureTest.java
When you perform multiple TX write operations in one transaction (put, replace, lock, etc) and one of the nodes goes down, there is a slight chance that some locks will be lost and acquired by another transaction.
So client ends up with two transactions holding the same lock on pessimistic cache at the same time. Both transactions commit at the end successfully.
I spent some time debugging infinispan code and found that PessimisticLockingInterceptor#releaseLocksOnFailureBeforePrepare releases all locks when OutdatedTopologyException occurs on remote node. But then StateTransferInterceptor#handleTxWriteCommand retries last command. This behavior produces inconsistent state - all locks before last command are released and any other transaction can acquire them.
I am attaching Test which reproduces this problem
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-6744) ClusterEvent doesn't implement CacheEntryExpired
by William Burns (JIRA)
William Burns created ISPN-6744:
-----------------------------------
Summary: ClusterEvent doesn't implement CacheEntryExpired
Key: ISPN-6744
URL: https://issues.jboss.org/browse/ISPN-6744
Project: Infinispan
Issue Type: Bug
Components: Expiration, Listeners
Reporter: William Burns
Assignee: William Burns
Fix For: 9.0.0.Alpha3
ClusterEvent needs to implement CacheEntryExpired or else it cannot be replicated as a cluster event in the event of an expiration not on a node where a cluster listener was registered.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-6743) Upsert does not work for MySQL
by Krzysztof Sobolewski (JIRA)
[ https://issues.jboss.org/browse/ISPN-6743?page=com.atlassian.jira.plugin.... ]
Krzysztof Sobolewski updated ISPN-6743:
---------------------------------------
Description:
ISPN-20, merged recently (thanks!), added "upsert" support for JDBC cache stores. The "upsert" SQL statement is database-type-dependent and the one for MySQL has a different "API" than the one for other database types - whereas all the others use the same number and order of placeholders as the equvalent INSERT statement, so that the same method can be used to update the INSERT, UPDATE and "upsert" statement, the MySQL one adds additional placeholders and the aforementioned method is no longer sufficient.
The exception is:
java.sql.SQLException: No value specified for parameter 4
was:
ISPN-20, merged recently (thanks!), added "upsert" support for JDBC cache stores. The "upsert" SQL statement is database-type-dependent and the one for MySQL has a different "API" than the one for other database types - whereas all the others use the same number and order of placeholders as the equvalent INSERT statement, so that the same method can be used to update the INSERT, UPDATE and "upsert" statement, the MySQL one adds additional placeholders and the aforementioned method is no longer sufficient.
The exception is:
java.sql.SQLException: No value specified for parameter 2
> Upsert does not work for MySQL
> ------------------------------
>
> Key: ISPN-6743
> URL: https://issues.jboss.org/browse/ISPN-6743
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha2
> Reporter: Krzysztof Sobolewski
>
> ISPN-20, merged recently (thanks!), added "upsert" support for JDBC cache stores. The "upsert" SQL statement is database-type-dependent and the one for MySQL has a different "API" than the one for other database types - whereas all the others use the same number and order of placeholders as the equvalent INSERT statement, so that the same method can be used to update the INSERT, UPDATE and "upsert" statement, the MySQL one adds additional placeholders and the aforementioned method is no longer sufficient.
> The exception is:
> java.sql.SQLException: No value specified for parameter 4
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-6743) Upsert does not work for MySQL
by Krzysztof Sobolewski (JIRA)
[ https://issues.jboss.org/browse/ISPN-6743?page=com.atlassian.jira.plugin.... ]
Krzysztof Sobolewski updated ISPN-6743:
---------------------------------------
Description:
ISPN-20, merged recently (thanks!), added "upsert" support for JDBC cache stores. The "upsert" SQL statement is database-type-dependent and the one for MySQL has a different "API" than the one for other database types - whereas all the others use the same number and order of placeholders as the equvalent INSERT statement, so that the same method can be used to update the INSERT, UPDATE and "upsert" statement, the MySQL one adds additional placeholders and the aforementioned method is no longer sufficient.
The exception is:
java.sql.SQLException: No value specified for parameter 2
was:ISPN-20, merged recently (thanks!), added "upsert" support for JDBC cache stores. The "upsert" SQL statement is database-type-dependent and the one for MySQL has a different "API" than the one for other database types - whereas all the others use the same number and order of placeholders as the equvalent INSERT statement, so that the same method can be used to update the INSERT, UPDATE and "upsert" statement, the MySQL one adds additional placeholders and the aforementioned method is no longer sufficient.
> Upsert does not work for MySQL
> ------------------------------
>
> Key: ISPN-6743
> URL: https://issues.jboss.org/browse/ISPN-6743
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha2
> Reporter: Krzysztof Sobolewski
>
> ISPN-20, merged recently (thanks!), added "upsert" support for JDBC cache stores. The "upsert" SQL statement is database-type-dependent and the one for MySQL has a different "API" than the one for other database types - whereas all the others use the same number and order of placeholders as the equvalent INSERT statement, so that the same method can be used to update the INSERT, UPDATE and "upsert" statement, the MySQL one adds additional placeholders and the aforementioned method is no longer sufficient.
> The exception is:
> java.sql.SQLException: No value specified for parameter 2
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-6743) Upsert does not work for MySQL
by Krzysztof Sobolewski (JIRA)
Krzysztof Sobolewski created ISPN-6743:
------------------------------------------
Summary: Upsert does not work for MySQL
Key: ISPN-6743
URL: https://issues.jboss.org/browse/ISPN-6743
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 9.0.0.Alpha2
Reporter: Krzysztof Sobolewski
ISPN-20, merged recently (thanks!), added "upsert" support for JDBC cache stores. The "upsert" SQL statement is database-type-dependent and the one for MySQL has a different "API" than the one for other database types - whereas all the others use the same number and order of placeholders as the equvalent INSERT statement, so that the same method can be used to update the INSERT, UPDATE and "upsert" statement, the MySQL one adds additional placeholders and the aforementioned method is no longer sufficient.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-6742) Console shows cache available and disabled at the same time
by Jiří Holuša (JIRA)
[ https://issues.jboss.org/browse/ISPN-6742?page=com.atlassian.jira.plugin.... ]
Jiří Holuša updated ISPN-6742:
------------------------------
Summary: Console shows cache available and disabled at the same time (was: Console shows cache available even when cache is disabled)
> Console shows cache available and disabled at the same time
> -----------------------------------------------------------
>
> Key: ISPN-6742
> URL: https://issues.jboss.org/browse/ISPN-6742
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.2.2.Final
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
> Attachments: attachment.png
>
>
> Page: go to cache detail and click "Actions" -> "Disable".
> After confirmation, the cache status is still "Available", but new red box appears with text "Disabled", see the attachment. This doesn't seem to me very intuitive, if the cache is disabled, it should be IMO unavailable and this should be also reflected in the caches list.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-6742) Console shows cache available even when cache is disabled
by Jiří Holuša (JIRA)
[ https://issues.jboss.org/browse/ISPN-6742?page=com.atlassian.jira.plugin.... ]
Jiří Holuša updated ISPN-6742:
------------------------------
Attachment: attachment.png
> Console shows cache available even when cache is disabled
> ---------------------------------------------------------
>
> Key: ISPN-6742
> URL: https://issues.jboss.org/browse/ISPN-6742
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.2.2.Final
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
> Attachments: attachment.png
>
>
> Page: go to cache detail and click "Actions" -> "Disable".
> After confirmation, the cache status is still "Available", but new red box appears with text "Disabled", see the attachment. This doesn't seem to me very intuitive, if the cache is disabled, it should be IMO unavailable and this should be also reflected in the caches list.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-6742) Console shows cache available even when cache is disabled
by Jiří Holuša (JIRA)
Jiří Holuša created ISPN-6742:
---------------------------------
Summary: Console shows cache available even when cache is disabled
Key: ISPN-6742
URL: https://issues.jboss.org/browse/ISPN-6742
Project: Infinispan
Issue Type: Bug
Components: Console
Affects Versions: 8.2.2.Final
Reporter: Jiří Holuša
Assignee: Vladimir Blagojevic
Page: go to cache detail and click "Actions" -> "Disable".
After confirmation, the cache status is still "Available", but new red box appears with text "Disabled", see the attachment. This doesn't seem to me very intuitive, if the cache is disabled, it should be IMO unavailable and this should be also reflected in the caches list.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-6740) Client topologies not updated when cache topology loaded from persistent state
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6740?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6740:
-------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4391
> Client topologies not updated when cache topology loaded from persistent state
> ------------------------------------------------------------------------------
>
> Key: ISPN-6740
> URL: https://issues.jboss.org/browse/ISPN-6740
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, State Transfer
> Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
> Reporter: Galder Zamarreño
> Assignee: Dan Berindei
> Fix For: 9.0.0.Alpha3, 9.0.0.Final
>
>
> Infinispan Caches now support storing persistent views. When these are loaded, these might be loaded with topology ID 0:
> {code}
> 2016-05-31 10:20:04,254 INFO [org.infinispan.globalstate.impl.GlobalStateManagerImpl] (MSC service thread 1-3)
> ISPN000389: Loaded global state, version=9.0.0-SNAPSHOT timestamp=2016-05-30T12:03:33.822Z
> ....
> 2016-05-31 10:20:07,867 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (MSC service thread 1-6)
> Installing new cache topology CacheTopology{id=0, rebalanceId=0, currentCH=DefaultConsistentHash{ns=20, owners = (3)[node5: 7+5, node4: 7+7, node6: 6+8]},
> pendingCH=null, unionCH=null, actualMembers=[node5, node4, node6], persistentUUIDs=[
> bb76729d-2b30-4e54-8108-4ac1db9a04cf, bb76729d-2b30-4e54-8108-4ac1db9a04cf, bb76729d-2b30-4e54-8108-4ac1db9a04cf]} on cache default
> {code}
> If there's no further view changes, the topology ID will remain 0. When a Hot Rod client first connects, it sends its view topology as 0 so that it receives a newly installed topology, but if the topology is already 0 in the server, the server won't send the installed topology, even though it should be newer than having no topology.
> We should start numbering topologies in server starting from 1 instead. That avoids this issue. This is easier than forcing clients to send -1 as initial topology because the topology ID is currently defined as VInt that can only 0 or positive number.
> Also, some extra log messages indicating that the cache topology installed comes from persisted state would be handy for debugging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months