[JBoss JIRA] (ISPN-3649) RemoteStoreRawValuesTest.testLoadAndStoreWithLifespanAndIdle && RemoteStoreTest.testLoadAndStoreWithIdle fails periodically on Windows2008R2
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3649?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3649:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021382, https://bugzilla.redhat.com/show_bug.cgi?id=1028339, https://bugzilla.redhat.com/show_bug.cgi?id=1138572 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1021382, https://bugzilla.redhat.com/show_bug.cgi?id=1028339)
> RemoteStoreRawValuesTest.testLoadAndStoreWithLifespanAndIdle && RemoteStoreTest.testLoadAndStoreWithIdle fails periodically on Windows2008R2
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3649
> URL: https://issues.jboss.org/browse/ISPN-3649
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores, Test Suite - Core
> Affects Versions: 6.0.0.CR1, 7.0.0.Alpha1, 7.0.0.Alpha2
> Environment: Windows 2008R2 && JDK6
> Reporter: Anna Manukyan
> Labels: testsuite_stability
>
> Tests fail randomly on Windows 2008R2 machine
> RemoteStoreRawValuesTest.testLoadAndStoreWithLifespanAndIdle
> The failure error is:
> {code}
> java.lang.AssertionError
> at org.infinispan.persistence.remote.RemoteStoreRawValuesTest.assertEventuallyExpires(RemoteStoreRawValuesTest.java:91)
> at org.infinispan.persistence.BaseStoreTest.testLoadAndStoreWithLifespanAndIdle(BaseStoreTest.java:211)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> 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:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> RemoteStoreTest.testLoadAndStoreWithIdle
> {code}
> java.lang.AssertionError
> at org.infinispan.persistence.remote.RemoteStoreTest.assertEventuallyExpires(RemoteStoreTest.java:89)
> at org.infinispan.persistence.BaseStoreTest.testLoadAndStoreWithIdle(BaseStoreTest.java:206)
> 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:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> 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:744)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 10 months
[JBoss JIRA] (ISPN-3395) ISPN000196: Failed to recover cluster state after the current node became the coordinator
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3395?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant resolved ISPN-3395.
-----------------------------------
Fix Version/s: 7.0.0.Final
Resolution: Done
> ISPN000196: Failed to recover cluster state after the current node became the coordinator
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-3395
> URL: https://issues.jboss.org/browse/ISPN-3395
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 5.3.0.Final
> Reporter: Mayank Agarwal
> Fix For: 7.0.0.Final
>
>
> We are using infinispan 5.3.0.Final in our distributed application. we are testing infinispan in HA scenarios and getting following exception when new node becomes co-ordinator.
> ISPN000196: Failed to recover cluster state after the current node became the coordinator
> java.lang.NullPointerException: null
> at org.infinispan.topology.ClusterTopologyManagerImpl.recoverClusterStatus(ClusterTopologyManagerImpl.java:455) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final]
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:235) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final]
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener$1.run(ClusterTopologyManagerImpl.java:647) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[na:1.6.0_25]
> at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) ~[na:1.6.0_25]
> at java.util.concurrent.FutureTask.run(Unknown Source) [na:1.6.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [na:1.6.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.6.0_25]
> at java.lang.Thread.run(Unknown Source) [na:1.6.0_25]
> This is happening because cacheTopology is null at ClusterTopologyManagerImpl.java:455
> at 449: code is checking cacheTopology for null that for loop which is updating cacheStatusMap at 457 should be in that check itself.
> Fix:
> --- a/core/src/main/java/org/infinispan/topology/ClusterTopologyManagerImpl.java
> +++ b/core/src/main/java/org/infinispan/topology/ClusterTopologyManagerImpl.java
> @@ -448,7 +448,7 @@ public class ClusterTopologyManagerImpl implements ClusterTopologyManager {
> // but didn't get a response back yet
> if (cacheTopology != null) {
> topologyList.add(cacheTopology);
> - }
> +
>
> // Add all the members of the topology that have sent responses first
> // If we only added the sender, we could end up with a different member order
> @@ -457,6 +457,7 @@ public class ClusterTopologyManagerImpl implements ClusterTopologyManager {
> cacheStatusMap.get(cacheName).addMember(member);
> }
> }
> + }
>
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 10 months
[JBoss JIRA] (ISPN-5040) Upgrade to JGroups 3.6.1.Final
by Dan Berindei (JIRA)
Dan Berindei created ISPN-5040:
----------------------------------
Summary: Upgrade to JGroups 3.6.1.Final
Key: ISPN-5040
URL: https://issues.jboss.org/browse/ISPN-5040
Project: Infinispan
Issue Type: Component Upgrade
Affects Versions: 7.1.0.Alpha1
Reporter: Dan Berindei
Fix For: 7.1.0.Beta1
When upgrading, we should remove the DISCARD2 protocol from Infinispan and we should configure NAKACK2 with {{resend_last_seqno=true}}.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 10 months
[JBoss JIRA] (ISPN-4433) Can not run INFINISPAN testsuite with JDK8
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4433?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4433:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1084904|https://bugzilla.redhat.com/show_bug.cgi?id=1084904] from NEW to ASSIGNED
> Can not run INFINISPAN testsuite with JDK8
> -------------------------------------------
>
> Key: ISPN-4433
> URL: https://issues.jboss.org/browse/ISPN-4433
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 7.0.0.Alpha4
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Fix For: 7.0.0.Alpha5
>
>
> {noformat}
> [ERROR] Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (default) on project infinispan-cachestore-jdbc: Execution default of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed. IllegalArgumentException -> [Help 1]
> [ERROR] Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (default) on project infinispan-lucene-v3: Execution default of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed. IllegalArgumentException -> [Help 1]
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack (unpack) on project infinispan-lucene-directory: Artifact has not been packaged yet. When used on reactor artifact, unpack should be executed after packaging: see MDEP-98. -> [Help 2]
> [ERROR] Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (default) on project infinispan-query: Execution default of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed. IllegalArgumentException -> [Help 1]
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project infinispan-tools: Compilation failure: Compilation failure:
> [ERROR] /mnt/hudson_workspace/workspace/edg-60-ispn-testsuite-rhel/89fa96e5/infinispan/tools/src/main/java/org/infinispan/tools/doclet/jmx/JmxDoclet.java:[67,32] cannot find symbol
> [ERROR] symbol: method getInstance()
> [ERROR] location: class com.sun.tools.doclets.formats.html.ConfigurationImpl
> [ERROR] /mnt/hudson_workspace/workspace/edg-60-ispn-testsuite-rhel/89fa96e5/infinispan/tools/src/main/java/org/infinispan/tools/doclet/jmx/JmxDoclet.java:[80,32] cannot find symbol
> [ERROR] symbol: method getInstance()
> [ERROR] location: class com.sun.tools.doclets.formats.html.ConfigurationImpl
> [ERROR] -> [Help 3]
> {noformat}
> Look on last Jenkins run with JDK8
> * RHEL5
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> * RHEL6
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 10 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4919:
------------------------------------
[~pferraro] you're right about the programmatic configuration, but in the XML configuration overriding still works exactly the same as in 4.x.
> Configuration templates
> -----------------------
>
> Key: ISPN-4919
> URL: https://issues.jboss.org/browse/ISPN-4919
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Beta1
>
>
> Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not.
> We should introduce the concept of configuration inheritance, e.g.:
> {code}
> <local-cache name="eviction-cache">
> <eviction strategy="LIRS" maxEntries="10000"/>
> </local-cache>
> <local-cache name="mycache" template="eviction-cache" />
> {code}
> Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.:
> {code}
> <local-cache name="eviction-cache" abstract="true">
> ...
> </local-cache>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 10 months
[JBoss JIRA] (ISPN-5016) Specify and document cache consistency guarantees
by Misha Ali (JIRA)
[ https://issues.jboss.org/browse/ISPN-5016?page=com.atlassian.jira.plugin.... ]
Misha Ali commented on ISPN-5016:
---------------------------------
Based on the discussion in the thread about this issue, there isn't much information available about what exactly we want to convey to users regarding ISPN or JDG's consistency guarantees. I'm looking into this for the product docs and wondered about this. Any thoughts, [~dan.berindei]?
> Specify and document cache consistency guarantees
> -------------------------------------------------
>
> Key: ISPN-5016
> URL: https://issues.jboss.org/browse/ISPN-5016
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Core
> Affects Versions: 7.0.2.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> We can't simply use the consistency model defined by Java Specification and broaden it for whole cache (maybe the expression "can't" is too strong, but we definitely don't want to do that in some cases).
> By consistency guarantees/model I mean mostly in which order are
> writes allowed to be observed: and we can't boil it down to simply
> causal, PRAM or any other consistency model as writes can be observed as non-atomic in Infinispan.
> Infinispan documentation is quite scarce about that, the only trace I've
> found is in Glossarry [2] "Infinispan has traditionally followed ACID
> principles as far as possible, however an eventually consistent mode
> embracing BASE is on the roadmap."
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 10 months