April 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5274) Inconsistent data after transaction rollback (with success on originator)

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5274?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5274: ------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/3380, https://github.com/infinispan/infinispan/pull/3404 (was: https://github.com/infinispan/infinispan/pull/3380) > Inconsistent data after transaction rollback (with success on originator) > ------------------------------------------------------------------------- > > Key: ISPN-5274 > URL: https://issues.jboss.org/browse/ISPN-5274 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.1.Final > Reporter: Matej Čimbora > Assignee: Dan Berindei > Fix For: 7.2.0.Final > > > Scenario > Nodes edg-perf[10-13], partition handling on > 1.Transaction is started on edg-perf10 > {code} > 10:24:48,228 TRACE [org.infinispan.transaction.xa.TransactionXaAdapter] (DefaultStressor-6) start called on tx GlobalTransaction:<edg-perf10-20667>:38910:local > {code} > 2. Value of key_000000000000065B is updated within the transaction > {code} > 10:24:48,405 TRACE [org.radargun.service.InfinispanOperations$Cache] (DefaultStressor-6) PUT cache=testCache key=key_000000000000065B value=[6 #15: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, 3147, ] > {code} > 3. Transaction is successfully prepared on edg-perf11 & edg-perf12 > {code} > 10:24:48,559 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-6) Responses: [sender=edg-perf11-61837, received=true, suspected=false] > [sender=edg-perf12-7305, received=true, suspected=false] > {code} > 4. Transaction commit is issued > {code} > 10:24:48,562 TRACE [org.infinispan.transaction.TransactionCoordinator] (DefaultStressor-6) Committing transaction GlobalTransaction:<edg-perf10-20667>:38910:local > {code} > 5. Other participating nodes (edg-perf11 & edg-perf12) are suspected... > {code} > 10:24:52,705 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (DefaultStressor-6) Target node edg-perf11-61837 left during remote call, ignoring > 10:24:52,716 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (DefaultStressor-6) Target node edg-perf12-7305 left during remote call, ignoring > {code} > ... as they received a new view (without edg-perf10) meanwhile. > {code} > 10:24:48,547 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,edg-perf12-7305) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf12-7305|20] (3) [edg-perf12-7305, edg-perf11-61837, edg-perf13-25187], 2 subgroups: [edg-perf13-25187|8] (1) [edg-perf13-25187], [edg-perf13-25187|19] (1) [edg-perf13-25187] > {code} > Still, the transaction is commited on edg-perf10 & updated entry is stored locally > {code} > 10:24:52,894 TRACE [org.infinispan.statetransfer.CommitManager] (DefaultStressor-6) Trying to commit. Key=key_000000000000065B. Operation Flag=null, L1 invalidation=false > 10:24:52,896 TRACE [org.infinispan.statetransfer.CommitManager] (DefaultStressor-6) Committing key=key_000000000000065B. It is a L1 invalidation or a normal put and no tracking is enabled! > 10:24:52,908 TRACE [org.infinispan.container.DefaultDataContainer] (DefaultStressor-6) Creating new ICE for writing. Existing=ImmortalCacheEntry{key=key_000000000000065B, value=[6 #14: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, ]}, metadata=EmbeddedMetadata{version=null}, new value=[6 #15: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, 3147, ] > {code} > 6. Other nodes rollback the transaction > {code} > 10:24:50,376 DEBUG [org.infinispan.transaction.TransactionTable] (transport-thread-10) Rolling back transaction GlobalTransaction:<edg-perf10-20667>:38910:remote because originator edg-perf10-20667 left the cluster > {code} > 7. edg-perf10 receives a new view, containing nodes edg-perf[10,11,13]. Incoming state transfer overwrites the updated value > {code} > 10:25:09,614 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,edg-perf10-20667) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf10-20667|22] (3) [edg-perf10-20667, edg-perf11-61837, edg-perf13-25187], 4 subgroups: [edg-perf10-20667|15] (2) [edg-perf10-20667, edg-perf11-61837], [edg-perf10-20667|19] (3) [edg-perf10-20667, edg-perf12-7305, edg-perf11-61837], [edg-perf10-20667|18] (1) [edg-perf10-20667], [edg-perf10-20667|21] (2) [edg-perf10-20667, edg-perf13-25187] > {code} > 8. get operation returns outdated value > {code} > 10:26:21,020 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (DefaultStressor-6) Response(s) to ClusteredGetCommand{key=key_000000000000065B, flags=null} is {edg-perf12-7305=SuccessfulResponse{responseValue=ImmortalCacheValue {value=[6 #14: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, ]}} } > {code} > From client perspective, this behavior is not transparent. Provided the transaction ended up successfully, presence of the updated entry can be assumed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5399) State transfer can hang if a node is joining just as the last member of a cache is leaving

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5399?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5399: ------------------------------- Status: Open (was: New) > State transfer can hang if a node is joining just as the last member of a cache is leaving > ------------------------------------------------------------------------------------------ > > Key: ISPN-5399 > URL: https://issues.jboss.org/browse/ISPN-5399 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.2.0.CR1, 7.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.2.0.Final > > > If a node is joining just as the last member of a cache is leaving, the ClusterCacheStatus on the coordinator may be updated incorrectly. The cache topology is reset to include only the joiner, but the joiner ignores it because the new topology id is set to 0. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5399) State transfer can hang if a node is joining just as the last member of a cache is leaving

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5399?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5399: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3404 > State transfer can hang if a node is joining just as the last member of a cache is leaving > ------------------------------------------------------------------------------------------ > > Key: ISPN-5399 > URL: https://issues.jboss.org/browse/ISPN-5399 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.2.0.CR1, 7.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.2.0.Final > > > If a node is joining just as the last member of a cache is leaving, the ClusterCacheStatus on the coordinator may be updated incorrectly. The cache topology is reset to include only the joiner, but the joiner ignores it because the new topology id is set to 0. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4546) Possible stale lock when the primary owner leaves during rebalance

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4546?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4546: ------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/3380, https://github.com/infinispan/infinispan/pull/3404 (was: https://github.com/infinispan/infinispan/pull/3380) > Possible stale lock when the primary owner leaves during rebalance > ------------------------------------------------------------------ > > Key: ISPN-4546 > URL: https://issues.jboss.org/browse/ISPN-4546 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.Alpha5, 7.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.2.0.Final > > > Topology T: coordinator = A, owners(k) = [C, D], pending_owners(k) = null > B sends prepareCommand(tx1, put(k, v)) to C, D > D adds backup locks and replies > C acquires lock, ready to send reply to B > A starts installing topology T+1: owners(k) = [C, D], pending_owners(k) = [C, E] > A, C and E install topology T+1, B and D do not > E requests and receives tx data from C, including tx1 > C leaves > B sees a SuspectException, sends rollbackCommand(tx1) to C, D > D removes tx1 > C has left, but is ignored > B reports to the user that the tx has been rolled back > B and D install topology T+1 (optional) > A starts installing topology T+2: owners(k) = [D], pending_owners(k) = [E] > A, B, D, E all install topology T+2 > E requests and receives state from D, but it does not remove tx1 > A starts installing topology T+3: owners(k) = [E], pending_owners(k) = null > E now has a stale backup lock on k > It seems very hard to reproduce in production: C would have to leave soon enough so that B and D haven't received the T+1 topology yet, but late enough for it to send its transaction data to E. > A possible solution would be to catch any SuspectException during prepare/commit/rollback (without ignoring leavers), wait for a new topology, and replicate the command again on the new owners. Obviously, this wouldn't work with asynchronous prepare/commit/rollback. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5399) State transfer can hang if a node is joining just as the last member of a cache is leaving

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5399: ---------------------------------- Summary: State transfer can hang if a node is joining just as the last member of a cache is leaving Key: ISPN-5399 URL: https://issues.jboss.org/browse/ISPN-5399 Project: Infinispan Issue Type: Bug Components: Core, State Transfer Affects Versions: 7.1.1.Final, 7.2.0.CR1 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.2.0.Final If a node is joining just as the last member of a cache is leaving, the ClusterCacheStatus on the coordinator may be updated incorrectly. The cache topology is reset to include only the joiner, but the joiner ignores it because the new topology id is set to 0. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5398) Run integration tests against WildFly 9.0.0.Beta2

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5398?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5398: ---------------------------------- Status: Open (was: New) > Run integration tests against WildFly 9.0.0.Beta2 > ------------------------------------------------- > > Key: ISPN-5398 > URL: https://issues.jboss.org/browse/ISPN-5398 > Project: Infinispan > Issue Type: Component Upgrade > Components: Test Suite - Core, Test Suite - Query > Affects Versions: 7.2.0.CR1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5397) Restore maxEntries(int) signature for backwards compatibility

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5397?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5397: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Restore maxEntries(int) signature for backwards compatibility > ------------------------------------------------------------- > > Key: ISPN-5397 > URL: https://issues.jboss.org/browse/ISPN-5397 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 7.2.0.CR1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3076) Infinispan should enable use of log4j2

by Mikhail Dobrinin (JIRA)

[ https://issues.jboss.org/browse/ISPN-3076?page=com.atlassian.jira.plugin.... ] Mikhail Dobrinin edited comment on ISPN-3076 at 4/21/15 11:21 AM: ------------------------------------------------------------------ Any chance for this to get finished? Log4j2 should be supported by jboss-logging as of 3.2.0. was (Author: mdobrinin): Any chance for this to get finished? Log4j2 should be supported by jboss-logging as of 3.2.1 - JBLOGGING-112. > Infinispan should enable use of log4j2 > -------------------------------------- > > Key: ISPN-3076 > URL: https://issues.jboss.org/browse/ISPN-3076 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 5.2.5.Final, 6.0.0.Final > Environment: Any > Reporter: Divya Mehra > Assignee: Tristan Tarrant > > log4j locks up on a certain amount of load, especially under concurrent access. The recommendation was to move up to log4j2. This can be done by removing > 1 JAR (log4j.jar) and adding 2 JARs (log4j-bridge and log4j-core.jar). > Also refer: https://issues.jboss.org/browse/ISPN-2976 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5398) Run integration tests against WildFly 9.0.0.Beta2

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5398: ------------------------------------- Summary: Run integration tests against WildFly 9.0.0.Beta2 Key: ISPN-5398 URL: https://issues.jboss.org/browse/ISPN-5398 Project: Infinispan Issue Type: Component Upgrade Components: Test Suite - Core, Test Suite - Query Affects Versions: 7.2.0.CR1 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 7.2.0.Final -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5397) Restore maxEntries(int) signature for backwards compatibility

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5397?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5397: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3402 > Restore maxEntries(int) signature for backwards compatibility > ------------------------------------------------------------- > > Key: ISPN-5397 > URL: https://issues.jboss.org/browse/ISPN-5397 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 7.2.0.CR1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2015