May 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3107) add javadoc to the HotRodServerConfigurationBuilder/HotRodServerConfiguration

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3107: ----------------------------------- Summary: add javadoc to the HotRodServerConfigurationBuilder/HotRodServerConfiguration Key: ISPN-3107 URL: https://issues.jboss.org/browse/ISPN-3107 Project: Infinispan Issue Type: Task Reporter: Mircea Markus Assignee: Tristan Tarrant these classes are lacking javadoc on their properties. There are some properties that are self explanatory such as host and port, but the ones related to topologyStateTransfer should be documented as I don't expect all the users to understand them out of the box. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3107) add javadoc to the HotRodServerConfigurationBuilder/HotRodServerConfiguration

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3107?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3107: -------------------------------- Priority: Minor (was: Major) > add javadoc to the HotRodServerConfigurationBuilder/HotRodServerConfiguration > ----------------------------------------------------------------------------- > > Key: ISPN-3107 > URL: https://issues.jboss.org/browse/ISPN-3107 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Tristan Tarrant > Priority: Minor > > these classes are lacking javadoc on their properties. There are some properties that are self explanatory such as host and port, but the ones related to topologyStateTransfer should be documented as I don't expect all the users to understand them out of the box. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3107) add javadoc to the HotRodServerConfigurationBuilder/HotRodServerConfiguration

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3107?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3107: -------------------------------- Fix Version/s: 5.3.0.Final > add javadoc to the HotRodServerConfigurationBuilder/HotRodServerConfiguration > ----------------------------------------------------------------------------- > > Key: ISPN-3107 > URL: https://issues.jboss.org/browse/ISPN-3107 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 5.3.0.Final > > > these classes are lacking javadoc on their properties. There are some properties that are self explanatory such as host and port, but the ones related to topologyStateTransfer should be documented as I don't expect all the users to understand them out of the box. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3063) Data Inconsistency when Recovery + syncCommitPhase=false

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3063?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-3063: ----------------------------------- if recovery is enabled, you have to send it in order to remove the transaction from the RecoveryManager (this is my understanding) > Data Inconsistency when Recovery + syncCommitPhase=false > -------------------------------------------------------- > > Key: ISPN-3063 > URL: https://issues.jboss.org/browse/ISPN-3063 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.2.5.Final, 5.3.0.Alpha1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Minor > Labels: recovery, transaction > > with syncCommitPhase=false, the CommitCommand is sent asynchronously. the TransactionCoordinator sends immediately the TxCompletionNotificationCommand that can be deliver first than the CommitCommand. The CommitCommand fails silently: > {code} > if (transaction == null) { > if (trace) log.tracef("Did not find a RemoteTransaction for %s", globalTx); > return invalidRemoteTxReturnValue(); > } > } > {code} > This bug affects the 5.3 and 5.2.5. I've made one test case to catch this bug: > 5.3 => https://github.com/pruivo/infinispan/blob/rec-async/core/src/test/java/or... > 5.2 => https://github.com/pruivo/infinispan/blob/rec-async-5.2/core/src/test/jav... > Note: this bug may happen if you use async communication (prepare in 1PC) > Note2: this may be related to https://issues.jboss.org/browse/ISPN-2719 > Possible solutions: > * do not allow to configure the cache with syncCommitPhase=false && recovery enabled; > * force syncCommitPhase=true when recovery is enabled; > * send the CommitCommand and the TxCompletionNotificationCommand as Regular Messages (they will be deliver in FIFO order) > Thanks to Diego Didona that spotted this bug. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2896) org.infinispan.lucene.DirectoryOnMultipleCachesTest.verifyIntendedLockCachesUsage fails randomly

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2896?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2896: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1822 I think that bug is caused by the removeAsync when the value == 0. Simplify code: {code:java} int refCount = refCountObject.intValue(); newValue = refCount - 1; locksCache.replace(readLockKey, refCountObject, newValue); if (newValue == 0) { locksCache.withFlags(Flag.IGNORE_RETURN_VALUES).removeAsync(readLockKey); } {code} So, when the assertion is done, the value can be zero or one. In case of zero, we need to check if the key is really removed. > org.infinispan.lucene.DirectoryOnMultipleCachesTest.verifyIntendedLockCachesUsage fails randomly > ------------------------------------------------------------------------------------------------ > > Key: ISPN-2896 > URL: https://issues.jboss.org/browse/ISPN-2896 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Affects Versions: 5.2.2.Final > Reporter: Anna Manukyan > Assignee: Sanne Grinovero > Labels: stable_embedded_query > Fix For: 5.3.0.CR1 > > > org.infinispan.lucene.DirectoryOnMultipleCachesTest.verifyIntendedLockCachesUsage fails randomly. The error message is: > {code} > java.lang.AssertionError > at org.infinispan.lucene.DirectoryOnMultipleCachesTest.verifyIntendedLockCachesUsage(DirectoryOnMultipleCachesTest.java:96) > 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:601) > 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$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > {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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3063) Data Inconsistency when Recovery + syncCommitPhase=false

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3063?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-3063: ------------------------------------ I think the TransactionCoordinator should not send a TxCompletionNotificationCommand at all if syncCommitPhase==false. There is a check already in AbstractEnlistmentAdapter.removeTransactionInfoRemotely, but maybe it's sent anyway when recovery is enabled. > Data Inconsistency when Recovery + syncCommitPhase=false > -------------------------------------------------------- > > Key: ISPN-3063 > URL: https://issues.jboss.org/browse/ISPN-3063 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.2.5.Final, 5.3.0.Alpha1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Minor > Labels: recovery, transaction > > with syncCommitPhase=false, the CommitCommand is sent asynchronously. the TransactionCoordinator sends immediately the TxCompletionNotificationCommand that can be deliver first than the CommitCommand. The CommitCommand fails silently: > {code} > if (transaction == null) { > if (trace) log.tracef("Did not find a RemoteTransaction for %s", globalTx); > return invalidRemoteTxReturnValue(); > } > } > {code} > This bug affects the 5.3 and 5.2.5. I've made one test case to catch this bug: > 5.3 => https://github.com/pruivo/infinispan/blob/rec-async/core/src/test/java/or... > 5.2 => https://github.com/pruivo/infinispan/blob/rec-async-5.2/core/src/test/jav... > Note: this bug may happen if you use async communication (prepare in 1PC) > Note2: this may be related to https://issues.jboss.org/browse/ISPN-2719 > Possible solutions: > * do not allow to configure the cache with syncCommitPhase=false && recovery enabled; > * force syncCommitPhase=true when recovery is enabled; > * send the CommitCommand and the TxCompletionNotificationCommand as Regular Messages (they will be deliver in FIFO order) > Thanks to Diego Didona that spotted this bug. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3097) Improve total order test suite

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3097?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3097: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1821 changes: * bugfix: the PrepareCommand was triggering the RollbackCommand if the CommitCommand arrives at the same as the PrepareCommand * the simple test cases extend a common base test implementation * added more tests varying the configuration * before each assertion, the test waits until all the nodes involved in the transaction sees commit it. > Improve total order test suite > ------------------------------ > > Key: ISPN-3097 > URL: https://issues.jboss.org/browse/ISPN-3097 > Project: Infinispan > Issue Type: Enhancement > Components: Transactions > Affects Versions: 5.3.0.Beta1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 5.3.0.Final > > > with async configurations, the total order test suite can make the assertions before the transaction reach all the nodes. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2910) Divide by zero exception on shutdown

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2910?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2910: ----------------------------------------------- Jitka Kudrnacova <jkudrnac(a)redhat.com> made a comment on [bug 920079|https://bugzilla.redhat.com/show_bug.cgi?id=920079] I looked at the release notes of 5.2.6.Final and this fix was not included. According to the JIRA, fix for this issue went to the 5.3.x. > Divide by zero exception on shutdown > ------------------------------------ > > Key: ISPN-2910 > URL: https://issues.jboss.org/browse/ISPN-2910 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.1.Final > Reporter: Paul Ferraro > Assignee: Dan Berindei > Fix For: 5.3.0.Alpha1, 5.3.0.Final > > > 19:40:50,671 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,shared=udp) ISPN000094: Received new cluster view: [perf20/web|13] [perf20/web, perf21/web] > 19:40:50,754 ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] (notification-thread-0) ISPN000196: Failed to recover cluster state after the current node became the coordinator: java.lang.ArithmeticException: / by zero > at org.infinispan.distribution.ch.DefaultConsistentHashFactory.addPrimaryOwners(DefaultConsistentHashFactory.java:130) > at org.infinispan.distribution.ch.DefaultConsistentHashFactory.rebalanceBuilder(DefaultConsistentHashFactory.java:124) > at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:86) > at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:45) > at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheStatusAfterMerge(ClusterTopologyManagerImpl.java:306) > at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:236) > at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.handleViewChange(ClusterTopologyManagerImpl.java:597) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_38] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_38] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_38] > at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_38] > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:212) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_38] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_38] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38] -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2910) Divide by zero exception on shutdown

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/ISPN-2910?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on ISPN-2910: -------------------------------------- Did the fix make it to 5.2.x? I can't seem to find it (maybe as part of something else?) > Divide by zero exception on shutdown > ------------------------------------ > > Key: ISPN-2910 > URL: https://issues.jboss.org/browse/ISPN-2910 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.1.Final > Reporter: Paul Ferraro > Assignee: Dan Berindei > Fix For: 5.3.0.Alpha1, 5.3.0.Final > > > 19:40:50,671 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,shared=udp) ISPN000094: Received new cluster view: [perf20/web|13] [perf20/web, perf21/web] > 19:40:50,754 ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] (notification-thread-0) ISPN000196: Failed to recover cluster state after the current node became the coordinator: java.lang.ArithmeticException: / by zero > at org.infinispan.distribution.ch.DefaultConsistentHashFactory.addPrimaryOwners(DefaultConsistentHashFactory.java:130) > at org.infinispan.distribution.ch.DefaultConsistentHashFactory.rebalanceBuilder(DefaultConsistentHashFactory.java:124) > at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:86) > at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:45) > at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheStatusAfterMerge(ClusterTopologyManagerImpl.java:306) > at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:236) > at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.handleViewChange(ClusterTopologyManagerImpl.java:597) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_38] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_38] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_38] > at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_38] > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:212) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_38] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_38] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38] -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2910) Divide by zero exception on shutdown

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2910?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2910: ----------------------------------------------- Ladislav Thon <lthon(a)redhat.com> made a comment on [bug 920079|https://bugzilla.redhat.com/show_bug.cgi?id=920079] Update from EAP 6.1.0.ER8 testing cycle: This issue was not seen during this cycle. This can mean that it was either fixed unintentionally (maybe as a by-product of the Infinispan upgrade to 5.2.6.Final) or this issue just became rarer. Either way, we decided not to close this issue. > Divide by zero exception on shutdown > ------------------------------------ > > Key: ISPN-2910 > URL: https://issues.jboss.org/browse/ISPN-2910 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.1.Final > Reporter: Paul Ferraro > Assignee: Dan Berindei > Fix For: 5.3.0.Alpha1, 5.3.0.Final > > > 19:40:50,671 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,shared=udp) ISPN000094: Received new cluster view: [perf20/web|13] [perf20/web, perf21/web] > 19:40:50,754 ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] (notification-thread-0) ISPN000196: Failed to recover cluster state after the current node became the coordinator: java.lang.ArithmeticException: / by zero > at org.infinispan.distribution.ch.DefaultConsistentHashFactory.addPrimaryOwners(DefaultConsistentHashFactory.java:130) > at org.infinispan.distribution.ch.DefaultConsistentHashFactory.rebalanceBuilder(DefaultConsistentHashFactory.java:124) > at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:86) > at org.infinispan.distribution.ch.DefaultConsistentHashFactory.updateMembers(DefaultConsistentHashFactory.java:45) > at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheStatusAfterMerge(ClusterTopologyManagerImpl.java:306) > at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:236) > at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.handleViewChange(ClusterTopologyManagerImpl.java:597) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_38] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_38] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_38] > at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_38] > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:212) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_38] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_38] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38] -- 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, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2013