April 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6047) Deadlock when a prepare command is retried

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6047?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6047: ------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/3988, https://github.com/infinispan/infinispan/pull/4289 (was: https://github.com/infinispan/infinispan/pull/3988) > Deadlock when a prepare command is retried > ------------------------------------------ > > Key: ISPN-6047 > URL: https://issues.jboss.org/browse/ISPN-6047 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 8.2.0.CR1, 8.1.4.Final > > > Looks like the ISPN-5623 fix went too far, and now I found a test failure with the opposite behaviour: > 1. Remote prepare for {{txA}} acquires lock {{K}} > 2. Remote prepare for {{txB}} blocks waiting for lock {{K}} > 3. The topology changes, and the {{txA}} prepare is retried > 4. The {{txA}} prepare times out, because it waits for pending transaction {{txB}} to finish. > So we have to make {{txA}} somehow know that it already has the lock after it received an {{UnsureResponse}} for the prepare command, and skip waiting for pending transactions. > I found the problem in a random failure of {{DistributedFourNodesMapReduceTest}} on a local branch, but I'm not sure if my local changes (making SyncCHF the default CH factory) made it more likely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6047) Deadlock when a prepare command is retried

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6047?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6047: ------------------------------ Fix Version/s: 8.1.4.Final > Deadlock when a prepare command is retried > ------------------------------------------ > > Key: ISPN-6047 > URL: https://issues.jboss.org/browse/ISPN-6047 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 8.2.0.CR1, 8.1.4.Final > > > Looks like the ISPN-5623 fix went too far, and now I found a test failure with the opposite behaviour: > 1. Remote prepare for {{txA}} acquires lock {{K}} > 2. Remote prepare for {{txB}} blocks waiting for lock {{K}} > 3. The topology changes, and the {{txA}} prepare is retried > 4. The {{txA}} prepare times out, because it waits for pending transaction {{txB}} to finish. > So we have to make {{txA}} somehow know that it already has the lock after it received an {{UnsureResponse}} for the prepare command, and skip waiting for pending transactions. > I found the problem in a random failure of {{DistributedFourNodesMapReduceTest}} on a local branch, but I'm not sure if my local changes (making SyncCHF the default CH factory) made it more likely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6505) Remote continuous query on a cache with compat mode enabled leads to CCE

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6505?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6505: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Final Resolution: Done > Remote continuous query on a cache with compat mode enabled leads to CCE > ------------------------------------------------------------------------ > > Key: ISPN-6505 > URL: https://issues.jboss.org/browse/ISPN-6505 > Project: Infinispan > Issue Type: Task > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: https://github.com/infinispan/infinispan/pull/4267 > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > See EmbeddedCompatContinuousQueryTest. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6116) query-dsl module shoud use jboss-logging

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6116?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6116: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > query-dsl module shoud use jboss-logging > ---------------------------------------- > > Key: ISPN-6116 > URL: https://issues.jboss.org/browse/ISPN-6116 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha2, 8.2.2.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6576) Functional API does not load values from cache loader on non-primary owners

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-6576?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-6576: ----------------------------------- So the problem is that when the function is executed on the backup (secondary) owner, the entry is not loaded, right? It seems that the intention was to avoid second load in case of shared cache store, but then the full value should be replicated to the backup owner, not just the function. [~galderz]? > Functional API does not load values from cache loader on non-primary owners > --------------------------------------------------------------------------- > > Key: ISPN-6576 > URL: https://issues.jboss.org/browse/ISPN-6576 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.1.Final > Reporter: Krzysztof Sobolewski > Attachments: AbstractFunctionalCachestoreTest.java, FunctionalCachestoreTestNonTx.java, FunctionalCachestoreTestTx.java > > > We have a cluster in DIST mode with numOwners > 1, so there are primary and secondary owners, with persistence enabled. When I do a read-write operation on the cluster using the Functional API on a key that is present in the cache loader, the entry that gets passed to the functional operation has a non-null value only for the primary owner. See: > org.infinispan.interceptors.ClusteredCacheLoaderInterceptor.skipLoadForWriteCommand() > line 53. > This is using non-transactional cache. > NOTE: The attached tests are modified version of the ones in ISPN-6573. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6518) org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6518?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-6518: --------------------------------------- PR merged to master and 8.2.x. Close when merged to 8.1.x. > org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly > -------------------------------------------------------------------------------- > > Key: ISPN-6518 > URL: https://issues.jboss.org/browse/ISPN-6518 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 8.1.3.Final, 8.2.1.Final, 9.0.0.Alpha1 > Reporter: Matej Čimbora > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 9.0.0.Alpha2, 8.1.4.Final, 8.2.2.Final, 9.0.0.Final > > > The issue was spotted in 6 hr soak tests and affects both distributed & replicated mode. > The test shows steady increase in heap usage. After closer examination of jfr recording, it seems that at the end of the test there are almost 22M live org.infinispan.transaction.xa.GlobalTransaction instances in the heap, totaling 667 MB in size. > Top heap consumers (final stage of the test) > Class Instances Size(bytes) Percentage of Heap(%) > byte[] 60,218 830,445,604 35.168 > Class Instances Size(bytes) Percentage of Heap(%) > org.infinispan.transaction.xa.GlobalTransaction 21,846,176 699,077,616 29.605 > Class Instances Size(bytes) Percentage of Heap(%) > java.util.concurrent.ConcurrentHashMap$Node 21,795,718 697,462,992 29.537 > Class Instances Size(bytes) Percentage of Heap(%) > java.util.concurrent.ConcurrentHashMap$Node[] 129 134,352,464 5.69 > Transaction configuration: > <transaction transaction-manager-lookup="org.infinispan.transaction.lookup.GenericTransactionManagerLookup" mode="NON_DURABLE_XA" /> > Please let me know if you'd like me to share more details from jfr recording. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6518) org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6518?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6518: ---------------------------------- Fix Version/s: 9.0.0.Alpha2 8.1.4.Final 8.2.2.Final 9.0.0.Final > org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly > -------------------------------------------------------------------------------- > > Key: ISPN-6518 > URL: https://issues.jboss.org/browse/ISPN-6518 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 8.1.3.Final, 8.2.1.Final, 9.0.0.Alpha1 > Reporter: Matej Čimbora > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 9.0.0.Alpha2, 8.1.4.Final, 8.2.2.Final, 9.0.0.Final > > > The issue was spotted in 6 hr soak tests and affects both distributed & replicated mode. > The test shows steady increase in heap usage. After closer examination of jfr recording, it seems that at the end of the test there are almost 22M live org.infinispan.transaction.xa.GlobalTransaction instances in the heap, totaling 667 MB in size. > Top heap consumers (final stage of the test) > Class Instances Size(bytes) Percentage of Heap(%) > byte[] 60,218 830,445,604 35.168 > Class Instances Size(bytes) Percentage of Heap(%) > org.infinispan.transaction.xa.GlobalTransaction 21,846,176 699,077,616 29.605 > Class Instances Size(bytes) Percentage of Heap(%) > java.util.concurrent.ConcurrentHashMap$Node 21,795,718 697,462,992 29.537 > Class Instances Size(bytes) Percentage of Heap(%) > java.util.concurrent.ConcurrentHashMap$Node[] 129 134,352,464 5.69 > Transaction configuration: > <transaction transaction-manager-lookup="org.infinispan.transaction.lookup.GenericTransactionManagerLookup" mode="NON_DURABLE_XA" /> > Please let me know if you'd like me to share more details from jfr recording. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (HRJS-5) Iterator.next might read another next calls entry

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/HRJS-5?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreño resolved HRJS-5. --------------------------------- Resolution: Rejected Not fault of the JS client. > Iterator.next might read another next calls entry > ------------------------------------------------- > > Key: HRJS-5 > URL: https://issues.jboss.org/browse/HRJS-5 > Project: Infinispan Javascript client > Issue Type: Bug > Affects Versions: 0.2.0 > Reporter: Galder Zamarreño > > Sometimes iterator fails with: > {code} > 2) Infinispan local client can iterate over entries > Message: > timeout: timed out after 5000 msec waiting for spec to complete > Stacktrace: > undefined > {code} > When you look at the trace logs, you see: > {code} > [2016-04-25 12:20:12.127] [TRACE] client - Invoke iterator.next(msgId=326,iteratorId=6bfd9ab1-d42f-4209-9393-90c13a648381) on 127.0.0.1:11222 > [2016-04-25 12:20:12.127] [TRACE] encoder - Encode operation with topology id 0 > [2016-04-25 12:20:12.127] [TRACE] transport - Write buffer(msgId=326) to 127.0.0.1:11222 > [2016-04-25 12:20:12.127] [TRACE] client - Invoke iterator.next(msgId=327,iteratorId=6bfd9ab1-d42f-4209-9393-90c13a648381) on 127.0.0.1:11222 > [2016-04-25 12:20:12.127] [TRACE] encoder - Encode operation with topology id 0 > [2016-04-25 12:20:12.128] [TRACE] transport - Write buffer(msgId=327) to 127.0.0.1:11222 > [2016-04-25 12:20:12.128] [TRACE] client - Invoke iterator.next(msgId=328,iteratorId=6bfd9ab1-d42f-4209-9393-90c13a648381) on 127.0.0.1:11222 > [2016-04-25 12:20:12.128] [TRACE] encoder - Encode operation with topology id 0 > [2016-04-25 12:20:12.128] [TRACE] transport - Write buffer(msgId=328) to 127.0.0.1:11222 > [2016-04-25 12:20:12.137] [TRACE] decoder - Read header(msgId=326): opCode=52, status=0, hasNewTopology=0 > [2016-04-25 12:20:12.137] [TRACE] decoder - Call decode for request(msgId=326) > [2016-04-25 12:20:12.137] [TRACE] iterator - Iterator next contains 1 entries > [2016-04-25 12:20:12.137] [TRACE] connection - After decoding request(msgId=326), buffer size is 23, and offset 23 > [2016-04-25 12:20:12.137] [TRACE] connection - Complete success for request(msgId=326) with [{"key":"local-it2","value":"v2"}] > [2016-04-25 12:20:12.138] [TRACE] decoder - Read header(msgId=328): opCode=52, status=0, hasNewTopology=0 > [2016-04-25 12:20:12.138] [TRACE] decoder - Call decode for request(msgId=328) > [2016-04-25 12:20:12.138] [TRACE] iterator - Iterator next contains 1 entries > [2016-04-25 12:20:12.138] [TRACE] connection - After decoding request(msgId=328), buffer size is 46, and offset 23 > [2016-04-25 12:20:12.138] [TRACE] decoder - Read header(msgId=328): opCode=52, status=0, hasNewTopology=0 > [2016-04-25 12:20:12.138] [TRACE] decoder - Call decode for request(msgId=328) > [2016-04-25 12:20:12.138] [TRACE] iterator - Iterator next contains 1 entries > [2016-04-25 12:20:12.138] [TRACE] connection - After decoding request(msgId=328), buffer size is 23, and offset 23 > [2016-04-25 12:20:12.139] [TRACE] connection - Complete success for request(msgId=328) with [{"key":"local-it1","value":"v1"}] > [2016-04-25 12:20:12.139] [TRACE] connection - Complete success for request(msgId=328) with [{"key":"local-it3","value":"v3"}] > [2016-04-25 12:20:17.963] [DEBUG] client - Invoke clear(msgId=329) > {code} > Two client side decode requests happened for msgId=328 whereas msgId=327 was left without answer. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6576) Functional API does not load values from cache loader on non-primary owners

by Krzysztof Sobolewski (JIRA)

Krzysztof Sobolewski created ISPN-6576: ------------------------------------------ Summary: Functional API does not load values from cache loader on non-primary owners Key: ISPN-6576 URL: https://issues.jboss.org/browse/ISPN-6576 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 8.2.1.Final Reporter: Krzysztof Sobolewski Attachments: AbstractFunctionalCachestoreTest.java, FunctionalCachestoreTestNonTx.java, FunctionalCachestoreTestTx.java We have a cluster in DIST mode with numOwners > 1, so there are primary and secondary owners, with persistence enabled. When I do a read-write operation on the cluster using the Functional API on a key that is present in the cache loader, the entry that gets passed to the functional operation has a non-null value only for the primary owner. See: org.infinispan.interceptors.ClusteredCacheLoaderInterceptor.skipLoadForWriteCommand() line 53. This is using non-transactional cache. NOTE: The attached tests are modified version of the ones in ISPN-6573. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6575) SkipOperation uses limit instead of skip

by Henrik Johansson (JIRA)

Henrik Johansson created ISPN-6575: -------------------------------------- Summary: SkipOperation uses limit instead of skip Key: ISPN-6575 URL: https://issues.jboss.org/browse/ISPN-6575 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 8.2.1.Final Reporter: Henrik Johansson The SkipOperation uses limit instead of skip. https://github.com/infinispan/infinispan/pull/4288 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2016