May 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2575) KeyTransformer registration is required on all nodes of the cluster, in case of custom keys

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2575: -------------------------------- Assignee: Adrian Nistor (was: Sanne Grinovero) > KeyTransformer registration is required on all nodes of the cluster, in case of custom keys > ------------------------------------------------------------------------------------------- > > Key: ISPN-2575 > URL: https://issues.jboss.org/browse/ISPN-2575 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Affects Versions: 5.2.0.Beta5 > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Attachments: ClusteredCacheTest.java > > > The case is the following: > I have a clustered cache on which I want to perform a search. I'm doing the following: > I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception: > java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer > When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager. > The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer() -- 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

2 weeks, 3 days

2
1
0 / 0

[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)

9 years, 5 months

1
0
0 / 0

[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)

9 years, 5 months

1
0
0 / 0

[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)

9 years, 5 months

1
0
0 / 0

[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)

9 years, 5 months

1
0
0 / 0

[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)

9 years, 5 months

1
0
0 / 0

[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)

9 years, 5 months

1
0
0 / 0

[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)

9 years, 5 months

1
0
0 / 0

[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)

9 years, 5 months

1
0
0 / 0

[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)

9 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2016