November 2017 - infinispan-issues

[JBoss JIRA] (ISPN-8533) Deadlock in pessimistic transaction

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-8533: --------------------------------- Summary: Deadlock in pessimistic transaction Key: ISPN-8533 URL: https://issues.jboss.org/browse/ISPN-8533 Project: Infinispan Issue Type: Bug Reporter: Pedro Ruivo Assignee: Pedro Ruivo Deadlock can happen (not sure how) during a topology change and pessimistic transaction. 2 transaction can end up in the pending lock manager and they will wait for each other to finish. {noformat} Caused by: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on xxxx in behalf of transaction GlobalTx:node-a:3746. Current owner GlobalTx:node-b:3629. at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:262) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitOn(DefaultPendingLockManager.java:345) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:147) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:166) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:134) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:234) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:41) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] {noformat} {noformat} Caused by: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on xxxx in behalf of transaction GlobalTx:node-b:3629. Current owner GlobalTx:node-a:3746. at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:262) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitOn(DefaultPendingLockManager.java:345) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:147) ~[infinispan-embedded-9.1.2.Final. jar:9.1.2.Final] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:166) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:134) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:234) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:41) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final] {noformat} notes: confirm the pending lock manager is cleanup! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8532) Add OpenShift 3.7 support

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created ISPN-8532: ----------------------------------------- Summary: Add OpenShift 3.7 support Key: ISPN-8532 URL: https://issues.jboss.org/browse/ISPN-8532 Project: Infinispan Issue Type: Bug Components: Cloud Integrations Reporter: Sebastian Łaskawiec In order to use the new set of icons we need to support OpenShift 3.7. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8406) Use number of owners provided by the user in Shared Memory Service

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8406?page=com.atlassian.jira.plugin.... ] Work on ISPN-8406 started by Ryan Emerson. ------------------------------------------ > Use number of owners provided by the user in Shared Memory Service > ------------------------------------------------------------------ > > Key: ISPN-8406 > URL: https://issues.jboss.org/browse/ISPN-8406 > Project: Infinispan > Issue Type: Enhancement > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Ryan Emerson > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8406) Use number of owners provided by the user in Shared Memory Service

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8406?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-8406. -------------------------------- Resolution: Done > Use number of owners provided by the user in Shared Memory Service > ------------------------------------------------------------------ > > Key: ISPN-8406 > URL: https://issues.jboss.org/browse/ISPN-8406 > Project: Infinispan > Issue Type: Enhancement > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Ryan Emerson > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8530) Default value of "merge-policy" xsd attribute should not be a lambda

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8530?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-8530: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5588 > Default value of "merge-policy" xsd attribute should not be a lambda > -------------------------------------------------------------------- > > Key: ISPN-8530 > URL: https://issues.jboss.org/browse/ISPN-8530 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.1.0.Final > Reporter: Adrian Nistor > Assignee: Ryan Emerson > Fix For: 9.2.0.Final > > > A different lambda name gets generated during each build. > So an xsd created and deployed to http://docs.jboss.org/infinispan/schemas/ becomes out of sync after next build. We can fix that by redeploying the schema but we cannot assume users will always re-fetch it. > Using static inner classes (non-anonymous) would be preferable in this case even though the lambda code looks nicer. This solution maintains backward compat with 9.1 too. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8462) Enable custom EntryMergePolicy deployments on the server

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8462?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-8462: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5588 > Enable custom EntryMergePolicy deployments on the server > -------------------------------------------------------- > > Key: ISPN-8462 > URL: https://issues.jboss.org/browse/ISPN-8462 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.2.0.Final > > > It should be possible for users to deploy custom implementations of the EntryMergePolicy interface in the same manner that custom cache stores are deployed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8440) Enable ConflictResolution on partition merge with PreferConsistencyStrategy

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8440?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-8440: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5588 > Enable ConflictResolution on partition merge with PreferConsistencyStrategy > --------------------------------------------------------------------------- > > Key: ISPN-8440 > URL: https://issues.jboss.org/browse/ISPN-8440 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 9.1.1.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.2.0.Final > > > Currently conflict resolution only occurs on a partition merge when the PreferAvailabilityStrategy is utilised (ALLOW_READ_WRITES). This should also occur when utilising the PreferConsistencyStrategy as it's possible for cache entries to become conflicted before a split-brain has been detected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8440) Enable ConflictResolution on partition merge with PreferConsistencyStrategy

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8440?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-8440: ------------------------------- Status: Open (was: New) > Enable ConflictResolution on partition merge with PreferConsistencyStrategy > --------------------------------------------------------------------------- > > Key: ISPN-8440 > URL: https://issues.jboss.org/browse/ISPN-8440 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 9.1.1.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.2.0.Final > > > Currently conflict resolution only occurs on a partition merge when the PreferAvailabilityStrategy is utilised (ALLOW_READ_WRITES). This should also occur when utilising the PreferConsistencyStrategy as it's possible for cache entries to become conflicted before a split-brain has been detected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8522) PreferAvailabilityStrategy conflict resolution should occur if an expected member is not in max topology

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8522?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-8522: ------------------------------- Status: Open (was: New) > PreferAvailabilityStrategy conflict resolution should occur if an expected member is not in max topology > -------------------------------------------------------------------------------------------------------- > > Key: ISPN-8522 > URL: https://issues.jboss.org/browse/ISPN-8522 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Alpha2 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.2.0.Beta2 > > > The current method for determining whether a split brain heal is occurring during an on merge event is wrong. Instead we should assume healing whenever one or more of the expected members is not in the membership of the maxTopology received. > Furthermore, we should also utilise the Union CH of all distinct CHs encountered for conflict resolution. This is necessary to ensure that we read the entries associated with all possible write owners before the rebalance occurs. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8522) PreferAvailabilityStrategy conflict resolution should occur if an expected member is not in max topology

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8522?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-8522: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5588 > PreferAvailabilityStrategy conflict resolution should occur if an expected member is not in max topology > -------------------------------------------------------------------------------------------------------- > > Key: ISPN-8522 > URL: https://issues.jboss.org/browse/ISPN-8522 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Alpha2 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.2.0.Beta2 > > > The current method for determining whether a split brain heal is occurring during an on merge event is wrong. Instead we should assume healing whenever one or more of the expected members is not in the membership of the maxTopology received. > Furthermore, we should also utilise the Union CH of all distinct CHs encountered for conflict resolution. This is necessary to ensure that we read the entries associated with all possible write owners before the rebalance occurs. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2017