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 Assignee: Mircea Markus The tests for the environment specified hang randomly on package org.infinispan.statetransfer. Due to not being able to login to executing machine at the moment I cannot provide logs/thread dump for the hanged tests. The logs would be attached later. -- 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, 2 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 > Affects Versions: 6.0.0.Beta2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 6.0.0.CR2, 6.0.0.Final > > > Currently the listener class is forced to be public. We should remove this check and accept any visibility and make the listener method accessible if needed. -- 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, 2 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 > 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 forced to be public. We should remove this check and accept any visibility and make the listener method accessible if needed. -- 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, 2 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 forced to be public. We should remove this check and accept any visibility and make the listener method accessible if needed. -- 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, 2 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 > 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

11 years, 2 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 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

11 years, 2 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 > --------------------------------------------------------------------- > > Key: ISPN-3422 > URL: https://issues.jboss.org/browse/ISPN-3422 > Project: Infinispan > Issue Type: Bug > Reporter: Dan Berindei > Assignee: Dan Berindei > > 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

11 years, 2 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 > 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

11 years, 2 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 > ----------------------------------------------------------------------------- > > Key: ISPN-3603 > URL: https://issues.jboss.org/browse/ISPN-3603 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.CR2, 6.0.0.Final > > > In non-tx cache, when conditional command (e.g. ReplaceCommand) fails on primary owner because the old value is not equal to current value, the NonTxDistributionInterceptor.visitReplaceCommand returns false but the entry is committed in EntryWrappingInterceptor anyway. > Speaking about EntryWrappingInterceptor.invokeNextAndApplyChanges: NonTxDistributionInterceptor does not mark the command as unsuccessful if it fails on the primary owner, therefore, checking for command.isSuccessful() in order to retry the command upon topology change may seem insufficient. -- 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, 2 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 > --------------------------------------------------------------------------------------------------------------------------- > > 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

11 years, 2 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