March 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2903) CLONE - Eviction causes lost AtomicMap entries

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2903: ---------------------------------------- ^ I did check the configuration, there were some differences, but didn't make a difference so far. > CLONE - Eviction causes lost AtomicMap entries > ---------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: jdg6 > Fix For: 5.2.4.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2903) CLONE - Eviction causes lost AtomicMap entries

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] Paul Ferraro edited comment on ISPN-2903 at 3/8/13 10:41 AM: ------------------------------------------------------------- Perhaps the cache isn't configured the same way in your test (within the Infinispan testsuite) as it is in ours? The cache in the AS test uses passivation to a file cache store. was (Author: pferraro): Perhaps the cache isn't configured the same way in your test (within the Infinispan testsuite) as it is in ours? The cache in the AS test has passivation to a file cache store enabled. > CLONE - Eviction causes lost AtomicMap entries > ---------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: jdg6 > Fix For: 5.2.4.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2847) Puts done by state transfer can fail with TimeoutException if lock cannot be acquired

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2847?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-2847: ------------------------------------- This happens because an older TX has a backup lock on this node and the state transfer has to wait for the old TX to finish first. I would suggest skipping the check for pending locks if current tx is a state transfer. > Puts done by state transfer can fail with TimeoutException if lock cannot be acquired > ------------------------------------------------------------------------------------- > > Key: ISPN-2847 > URL: https://issues.jboss.org/browse/ISPN-2847 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.2.Final, 5.3.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 5.2.x > Fix For: 5.3.0.Final > > > On pessimistic tx caches state transfer can fail for individual keys if they are locked by another tx for too long and timeout expires for the state transfer tx. The error is logged but nothing is done to try to recover the error. The value is lost. > This can be reproduced easily by running OperationsDuringStateTransferTest configured with pessimistic tx. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2847) Puts done by state transfer can fail with TimeoutException if lock cannot be acquired

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-2847?page=com.atlassian.jira.plugin.... ] Work on ISPN-2847 started by Adrian Nistor. > Puts done by state transfer can fail with TimeoutException if lock cannot be acquired > ------------------------------------------------------------------------------------- > > Key: ISPN-2847 > URL: https://issues.jboss.org/browse/ISPN-2847 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.2.Final, 5.3.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 5.2.x > Fix For: 5.3.0.Final > > > On pessimistic tx caches state transfer can fail for individual keys if they are locked by another tx for too long and timeout expires for the state transfer tx. The error is logged but nothing is done to try to recover the error. The value is lost. > This can be reproduced easily by running OperationsDuringStateTransferTest configured with pessimistic tx. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2903) CLONE - Eviction causes lost AtomicMap entries

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-2903: ------------------------------------ Perhaps the cache isn't configured the same way in your test (within the Infinispan testsuite) as it is in ours? The cache in the AS test has passivation to a file cache store enabled. > CLONE - Eviction causes lost AtomicMap entries > ---------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: jdg6 > Fix For: 5.2.4.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2903) CLONE - Eviction causes lost AtomicMap entries

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-2903: ------------------------------------ Yes - this test is failing at exactly the same spot as it was before. > CLONE - Eviction causes lost AtomicMap entries > ---------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: jdg6 > Fix For: 5.2.4.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2903) CLONE - Eviction causes lost AtomicMap entries

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] Paul Ferraro edited comment on ISPN-2903 at 3/8/13 9:58 AM: ------------------------------------------------------------ This test is not part of the AS testsuite because it does not test any integration code. If anything, it belongs in the Infinispan testsuite (without the AS test harness, of course). This test merely validates that AtomicMap entries are not lost upon eviction - and was explicitly setup to reproduce the linked EAP issue. was (Author: pferraro): This test is not part of the AS testsuite because it does not test any integration code. It's actually testing Infinispan code, i.e. it merely validates that AtomicMap entries are not lost upon eviction. > CLONE - Eviction causes lost AtomicMap entries > ---------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: jdg6 > Fix For: 5.2.4.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2903) CLONE - Eviction causes lost AtomicMap entries

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-2903: ------------------------------------ This test is not part of the AS testsuite because it does not test any integration code. It's actually testing Infinispan code, i.e. it merely validates that AtomicMap entries are not lost upon eviction. > CLONE - Eviction causes lost AtomicMap entries > ---------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: jdg6 > Fix For: 5.2.4.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2891) Gap in time between commit of transaction and actual value update

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-2891?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-2891: ---------------------------------- Summary: Gap in time between commit of transaction and actual value update (was: Calls to replace don't update cache until after tx commits) > Gap in time between commit of transaction and actual value update > ----------------------------------------------------------------- > > Key: ISPN-2891 > URL: https://issues.jboss.org/browse/ISPN-2891 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.2.1.Final > Reporter: Jim Crossley > Assignee: Galder Zamarreño > Labels: 5.2.x > Fix For: 5.3.0.Alpha1, 5.3.0.Final > > Attachments: bad.log, good.log, ugly.log > > > Since upgrading our AS7.2 dependency in Immutant (transitively pulling in 5.2.1.Final), one of our integration tests has begun failing intermittently on our CI server. We've yet to see the failure in local runs, only on CI, so I suspect there's something racist going on. > The two tests (one for optimistic locking, the other for pessimistic) integrate an Infinispan cache (on which the Immutant cache is built) with HornetQ and XA transactions. A number of queue listeners respond to messages by attempting to increment a value in the cache. The failure occurs with both locking schemes, but much more often with optimistic. > We've confirmed the failure on 5.2.2 as well. > Attached you'll find three traces of the optimistic test: the good, the bad, and the ugly. All three correspond to this test: https://github.com/immutant/immutant/blob/31a2ef6222088ccb828898e9e3e4531... > So you can correlate the log messages prefixed with "JC:" in the traces to the code. Note in particular the last two lines in locking.clj: a logged message containing the count, and then an assertion of the count. Note that the "bad" trace was an actual failing test, but the "ugly" trace was a successful test, even though the trace clearly shows the count logged as 2, not 3. The Infinispan TRACE output clearly shows the value as 3, hence the ugliness of this test. > It's important to understand that the "work" function occurs within an XA transaction. This means, as I understand it, that if three messages are published to "/queue/done", the cached count should equal 3. Line #44 in locking.clj will block until it receives 3 messages, after which the cached count should be 3. > These tests always pass locally. They only ever fail on CI, which runs *very* slowly. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2903) CLONE - Eviction causes lost AtomicMap entries

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2903: ---------------------------------------- I tried to modify the original test case I created for Infinispan to see if it failed but couldn't get it to fail. I've tried running it on AS8 and it fails in the same place as it did before: org.jboss.as.test.clustering.cluster.AtomicMapTestCase.test(AtomicMapTestCase.java:107) I'll try to add some more TRACE to see more closely how the contents of the AtomicHashMap progress. > CLONE - Eviction causes lost AtomicMap entries > ---------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: jdg6 > Fix For: 5.2.4.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. -- 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

11 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2013