June 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6745) Locks are lost in pessimistic cache

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6745?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6745: ------------------------------ Status: Open (was: New) > 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 > Assignee: Pedro Ruivo > 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 Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6745?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6745: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4428 > 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 > Assignee: Pedro Ruivo > 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] (IPROTO-7) Make protostream jdk9 compatible

by Adrian Nistor (JIRA)

Adrian Nistor created IPROTO-7: ---------------------------------- Summary: Make protostream jdk9 compatible Key: IPROTO-7 URL: https://issues.jboss.org/browse/IPROTO-7 Project: Infinispan ProtoStream Issue Type: Bug Reporter: Adrian Nistor -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6801) TransactionXaAdapter and SynchronizationAdapter are too big

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6801?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6801: ------------------------------- Status: Open (was: New) > TransactionXaAdapter and SynchronizationAdapter are too big > ----------------------------------------------------------- > > Key: ISPN-6801 > URL: https://issues.jboss.org/browse/ISPN-6801 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 9.0.0.Alpha3 > > > Most fields in {{TransactionXaAdapter}} and {{SynchronizationAdapter}} can be stored in the {{TransactionTable}}. That would save a bit of memory and CPU for each transaction. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6801) TransactionXaAdapter and SynchronizationAdapter are too big

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6801?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6801: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4427 > TransactionXaAdapter and SynchronizationAdapter are too big > ----------------------------------------------------------- > > Key: ISPN-6801 > URL: https://issues.jboss.org/browse/ISPN-6801 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 9.0.0.Alpha3 > > > Most fields in {{TransactionXaAdapter}} and {{SynchronizationAdapter}} can be stored in the {{TransactionTable}}. That would save a bit of memory and CPU for each transaction. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6801) TransactionXaAdapter and SynchronizationAdapter are too big

by Dan Berindei (JIRA)

Dan Berindei created ISPN-6801: ---------------------------------- Summary: TransactionXaAdapter and SynchronizationAdapter are too big Key: ISPN-6801 URL: https://issues.jboss.org/browse/ISPN-6801 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.0.0.Alpha2 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Minor Fix For: 9.0.0.Alpha3 Most fields in {{TransactionXaAdapter}} and {{SynchronizationAdapter}} can be stored in the {{TransactionTable}}. That would save a bit of memory and CPU for each transaction. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6800) Remove MultipleRpcCommand

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6800?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6800: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4426 > Remove MultipleRpcCommand > ------------------------- > > Key: ISPN-6800 > URL: https://issues.jboss.org/browse/ISPN-6800 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha3 > > > Having {{MultipleRpcCommand}} makes some things more complex than they should be, e.g. {{CacheRpcCommandExternalizer}} needs a thread-local because of it. > It was only used by the replication queue, which has been already removed in ISPN-6417. So it's safe to remove it completely and simplify {{CacheRpcCommandExternalizer}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6800) Remove MultipleRpcCommand

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6800?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6800: ------------------------------- Status: Open (was: New) > Remove MultipleRpcCommand > ------------------------- > > Key: ISPN-6800 > URL: https://issues.jboss.org/browse/ISPN-6800 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha3 > > > Having {{MultipleRpcCommand}} makes some things more complex than they should be, e.g. {{CacheRpcCommandExternalizer}} needs a thread-local because of it. > It was only used by the replication queue, which has been already removed in ISPN-6417. So it's safe to remove it completely and simplify {{CacheRpcCommandExternalizer}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6800) Remove MultipleRpcCommand

by Dan Berindei (JIRA)

Dan Berindei created ISPN-6800: ---------------------------------- Summary: Remove MultipleRpcCommand Key: ISPN-6800 URL: https://issues.jboss.org/browse/ISPN-6800 Project: Infinispan Issue Type: Task Components: Core Affects Versions: 9.0.0.Alpha2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.0.0.Alpha3 Having {{MultipleRpcCommand}} makes some things more complex than they should be, e.g. {{CacheRpcCommandExternalizer}} needs a thread-local because of it. It was only used by the replication queue, which has been already removed in ISPN-6417. So it's safe to remove it completely and simplify {{CacheRpcCommandExternalizer}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3905) Murmurhash3 implementation is slow on String keys

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3905?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3905: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4425 > Murmurhash3 implementation is slow on String keys > ------------------------------------------------- > > Key: ISPN-3905 > URL: https://issues.jboss.org/browse/ISPN-3905 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 6.0.0.Final, 6.0.1.Final > Reporter: Sanne Grinovero > Assignee: Dan Berindei > Priority: Minor > Labels: performance > > String instances are a common choice for being used as key entries, still the getBytes() operation being performed allocates costly buffers, and the computation to get those bytes looks like expensive too. > I suspect there might be good reasons for not using the String's own hashcode directly as an input to Murmurhash? Still that's what other implementations seem to do. -- 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 June 2016