October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3652) Some tests from org.infinispan.statetransfer package hang on Windows 2012 with JDK6

by Anna Manukyan (JIRA)

Anna Manukyan created ISPN-3652: ----------------------------------- Summary: Some tests from org.infinispan.statetransfer package hang on Windows 2012 with JDK6 Key: ISPN-3652 URL: https://issues.jboss.org/browse/ISPN-3652 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 6.0.0.CR1 Environment: Windows 2012 && JDK6 Reporter: Anna Manukyan … [View More]

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3651) Allow @Listener classes to be non-public

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3651?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3651: -------------------------------- Fix Version/s: 6.0.0.Final > Allow @Listener classes to be non-public > ---------------------------------------- > > Key: ISPN-3651 > URL: https://issues.jboss.org/browse/ISPN-3651 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners … [View More]

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3651) Allow @Listener classes to be non-public

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3651?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3651: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2152 > Allow @Listener classes to be non-public > ---------------------------------------- > > Key: ISPN-3651 > URL: https://issues.jboss.org/browse/ISPN-3651 > … [View More]

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3651) Allow @Listener classes to be non-public

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-3651: ----------------------------------- Summary: Allow @Listener classes to be non-public Key: ISPN-3651 URL: https://issues.jboss.org/browse/ISPN-3651 Project: Infinispan Issue Type: Enhancement Components: Listeners Affects Versions: 6.0.0.Beta2 Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 6.0.0.CR2 Currently the listener class is … [View More]

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3422) In non-tx caches, write operations may not be atomic during rebalance

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3422: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021461 > In non-tx caches, write operations may not be atomic during rebalance > --------------------------------------------------------------------- > > Key: ISPN-3422 > … [View More]

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3422) In non-tx caches, write operations may not be atomic during rebalance

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3422: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 1021461|https://bugzilla.redhat.com/show_bug.cgi?id=1021461] If the cache topology changes while a write command is running and before it has actually committed the entry to the data container, we retry the command (see ISPN-3366 and ISPN-3357). But … [View More]before we detect the topology change, one or more of the backup owners may have already applied the modification. Retrying the command re-acquires the key lock on the primary owner (even if the primary owner didn't change). That means another command could have modified the same key in the meantime, but the retried command is going to ignore any changes and is going to return the value before the first attempt. I have observed a situation where two concurrent putIfAbsent operations are retried because of topology change, and the second retry has overwritten the first retry. > In non-tx caches, write operations may not be atomic during rebalance > --------------------------------------------------------------------- > > Key: ISPN-3422 > URL: https://issues.jboss.org/browse/ISPN-3422 > Project: Infinispan > Issue Type: Bug > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > > If the cache topology changes while a write command is running and before it has actually committed the entry to the data container, we retry the command (see ISPN-3366 and ISPN-3357). But before we detect the topology change, one or more of the backup owners may have already applied the modification. > Retrying the command re-acquires the key lock on the primary owner (even if the primary owner didn't change). That means another command could have modified the same key in the meantime, but the retried command is going to ignore any changes and is going to return the value before the first attempt. Obviously, the command is not retried if the first attempt is not successful, but scenarios like this are possible: > {code} > thread 1: putIfAbsent(k, v1) -> null > thread 2: putIfAbsent(k, v2) -> null > {code} -- 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 [View Less]

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3422) In non-tx caches, write operations may not be atomic during rebalance

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3422: ----------------------------------- I have actually observed a situation where two concurrent putIfAbsent operations are retried because of topology change, and the second retry has overwritten the first retry. > In non-tx caches, write operations may not be atomic during rebalance > --------------------------------------------------------------------- &… [View More]

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3422) In non-tx caches, write operations may not be atomic during rebalance

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-3422: ------------------------------ Priority: Critical (was: Major) > In non-tx caches, write operations may not be atomic during rebalance > --------------------------------------------------------------------- > > Key: ISPN-3422 > URL: https://issues.jboss.org/browse/ISPN-3422 > Project: Infinispan > … [View More]

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3603) Conditional command is committed on originator when it fails on primary owner

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3603: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1016499|https://bugzilla.redhat.com/show_bug.cgi?id=1016499] from ON_QA to VERIFIED > Conditional command is committed on originator when it fails on primary owner > ----------------------------------------------------------------… [View More]

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3646) org.infinispan.distribution.DistSyncL1PessimisticFuncTest.testWriteLockBlockingForceWriteL1Update fails on Windows machines

by Vitalii Chepeliuk (JIRA)

[ https://issues.jboss.org/browse/ISPN-3646?page=com.atlassian.jira.plugin.... ] Vitalii Chepeliuk updated ISPN-3646: ------------------------------------ Attachment: DistSyncL1PessimisticFuncTest.log.zip Added trace log for DistSyncL1PessimisticFuncTest > org.infinispan.distribution.DistSyncL1PessimisticFuncTest.testWriteLockBlockingForceWriteL1Update fails on Windows machines > --------------------------------------------------------------------------------------… [View More]------------------------------------- > > Key: ISPN-3646 > URL: https://issues.jboss.org/browse/ISPN-3646 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 6.0.0.CR1 > Environment: Windows 2008R2 & Windows 2012, JDK7 > Reporter: Anna Manukyan > Assignee: William Burns > Labels: testsuite_stability > Attachments: DistSyncL1PessimisticFuncTest.log.zip > > > The test org.infinispan.distribution.DistSyncL1PessimisticFuncTest.testWriteLockBlockingForceWriteL1Update fails constantly on windows machines with the following error: > java.lang.AssertionError: expected:<some-new-value> but was:<some-value> > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108) > at org.infinispan.distribution.DistSyncL1PessimisticFuncTest.testWriteLockBlockingForceWriteL1Update(DistSyncL1PessimisticFuncTest.java:90) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:715) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) -- 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 [View Less]

11 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 October 2013