[JBoss JIRA] (ISPN-4515) Create repository for lucene wildfly modules
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-4515?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes resolved ISPN-4515.
-------------------------------------
Resolution: Done
> Create repository for lucene wildfly modules
> ----------------------------------------------
>
> Key: ISPN-4515
> URL: https://issues.jboss.org/browse/ISPN-4515
> Project: Infinispan
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Lucene Directory
> Affects Versions: 7.0.0.Alpha4, 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 7.0.0.Beta1
>
>
> In order to standardize the Lucene directory modules for Wildfly usage across projects, so that a single "slot" is used, and to be able to evolve it independently from Infinispan releases, we need to create a new repository & Maven project
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4515) Create repository for lucene wildfly modules
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-4515?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-4515:
------------------------------------
Affects Version/s: 7.0.0.Alpha5
> Create repository for lucene wildfly modules
> ----------------------------------------------
>
> Key: ISPN-4515
> URL: https://issues.jboss.org/browse/ISPN-4515
> Project: Infinispan
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Lucene Directory
> Affects Versions: 7.0.0.Alpha4, 7.0.0.Alpha5
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> In order to standardize the Lucene directory modules for Wildfly usage across projects, so that a single "slot" is used, and to be able to evolve it independently from Infinispan releases, we need to create a new repository & Maven project
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-3811) Initial ST leaves node as member without data after MERGE
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3811?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3811:
-------------------------------
Priority: Blocker (was: Critical)
> Initial ST leaves node as member without data after MERGE
> ---------------------------------------------------------
>
> Key: ISPN-3811
> URL: https://issues.jboss.org/browse/ISPN-3811
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
>
> Under certain circumstances, JGroups can issue a MERGE view when a node is joining the cache. The new node joins the cluster, and all nodes have the same cache topology (not containing the joiner yet).
> During the merge, the CH's are joined (through CHFactory.union) and as all report the same topology/hash, the resulting hash is identical. However, the joiner is added to the members list and therefore it can finish the initial state transfer, although no data have been assigned to him.
> Later, the coordinator starts rebalance and the node begins to receive some data, but the thread which started the cluster manager (and should wait until the cluster becomes properly replicated through initial ST) is already released.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-3811) Initial ST leaves node as member without data after MERGE
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3811?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3811:
-------------------------------
Labels: testsuite_stability (was: )
> Initial ST leaves node as member without data after MERGE
> ---------------------------------------------------------
>
> Key: ISPN-3811
> URL: https://issues.jboss.org/browse/ISPN-3811
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
>
> Under certain circumstances, JGroups can issue a MERGE view when a node is joining the cache. The new node joins the cluster, and all nodes have the same cache topology (not containing the joiner yet).
> During the merge, the CH's are joined (through CHFactory.union) and as all report the same topology/hash, the resulting hash is identical. However, the joiner is added to the members list and therefore it can finish the initial state transfer, although no data have been assigned to him.
> Later, the coordinator starts rebalance and the node begins to receive some data, but the thread which started the cluster manager (and should wait until the cluster becomes properly replicated through initial ST) is already released.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-3811) Initial ST leaves node as member without data after MERGE
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3811?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3811:
------------------------------------
I just saw this happening in StateTransferFunctionalTest.
After a merge/coordinator change, the new coordinator is supposed to add the new members to the CH, but not as owners for any segments. However, in replicated mode, all the members of the CH are considered owners, so the joiner can become a regular owner without actually receiving the data.
> Initial ST leaves node as member without data after MERGE
> ---------------------------------------------------------
>
> Key: ISPN-3811
> URL: https://issues.jboss.org/browse/ISPN-3811
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
>
> Under certain circumstances, JGroups can issue a MERGE view when a node is joining the cache. The new node joins the cluster, and all nodes have the same cache topology (not containing the joiner yet).
> During the merge, the CH's are joined (through CHFactory.union) and as all report the same topology/hash, the resulting hash is identical. However, the joiner is added to the members list and therefore it can finish the initial state transfer, although no data have been assigned to him.
> Later, the coordinator starts rebalance and the node begins to receive some data, but the thread which started the cluster manager (and should wait until the cluster becomes properly replicated through initial ST) is already released.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-3811) Initial ST leaves node as member without data after MERGE
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3811?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3811:
-------------------------------
Priority: Critical (was: Major)
> Initial ST leaves node as member without data after MERGE
> ---------------------------------------------------------
>
> Key: ISPN-3811
> URL: https://issues.jboss.org/browse/ISPN-3811
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> Under certain circumstances, JGroups can issue a MERGE view when a node is joining the cache. The new node joins the cluster, and all nodes have the same cache topology (not containing the joiner yet).
> During the merge, the CH's are joined (through CHFactory.union) and as all report the same topology/hash, the resulting hash is identical. However, the joiner is added to the members list and therefore it can finish the initial state transfer, although no data have been assigned to him.
> Later, the coordinator starts rebalance and the node begins to receive some data, but the thread which started the cluster manager (and should wait until the cluster becomes properly replicated through initial ST) is already released.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-3741) DistAsyncFuncTest / TopologyAwareDistAsyncFuncTest random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3741?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3741:
-------------------------------
Priority: Blocker (was: Major)
> DistAsyncFuncTest / TopologyAwareDistAsyncFuncTest random failures
> ------------------------------------------------------------------
>
> Key: ISPN-3741
> URL: https://issues.jboss.org/browse/ISPN-3741
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Core
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
>
> {{DistAsyncFuncTest.asyncWait()}} is not correct with the new non-tx locking scheme. The the originator (B) doesn't update the entry when it first executes the command, only when it executes it the second time (when it's forwarded back by C).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4312) Distributed(Intermediate)SharedCacheFourNodesMapReduceTest randomly fails on Windows
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4312?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4312:
-------------------------------
Priority: Blocker (was: Major)
> Distributed(Intermediate)SharedCacheFourNodesMapReduceTest randomly fails on Windows
> ------------------------------------------------------------------------------------
>
> Key: ISPN-4312
> URL: https://issues.jboss.org/browse/ISPN-4312
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Core
> Affects Versions: 7.0.0.Alpha4
> Environment: Windows machines, 2k8r2, 2k12r2
> Reporter: Tomas Sykora
> Assignee: Vladimir Blagojevic
> Priority: Blocker
> Labels: testsuite_stability
>
> It looks like tests have problems with fitting into 15 sec timeout on Windows.
> org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: Reduce phase executing at DistributedSharedCacheFourNodesMapReduceTest-NodeA-36515 did not complete within 15 sec timeout
> at org.infinispan.distexec.mapreduce.MapReduceTask.executeHelper(MapReduceTask.java:498)
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:447)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.testInvokeMapReduceOnAllKeysWithResultCache(BaseWordCountMapReduceTest.java:173)
> 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: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$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)
> Caused by: java.util.concurrent.ExecutionException: Reduce phase executing at DistributedSharedCacheFourNodesMapReduceTest-NodeA-36515 did not complete within 15 sec timeout
> at org.infinispan.distexec.mapreduce.MapReduceTask.executeReducePhase(MapReduceTask.java:748)
> at org.infinispan.distexec.mapreduce.MapReduceTask.executeHelper(MapReduceTask.java:495)
> ... 23 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: Node DistributedSharedCacheFourNodesMapReduceTest-NodeD-54406 timed out
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:174)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:280)
> at org.infinispan.remoting.rpc.RpcManagerImpl$2.call(RpcManagerImpl.java:312)
> ... 5 more
> Caused by: org.jgroups.TimeoutException: timeout sending message to DistributedSharedCacheFourNodesMapReduceTest-NodeD-54406
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:419)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:349)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> ... 8 more
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4312) Distributed(Intermediate)SharedCacheFourNodesMapReduceTest randomly fails on Windows
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4312?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4312:
------------------------------------
Still seeing sporadic failures in CI, e.g. http://ci.infinispan.org/viewLog.html?buildId=9213&tab=buildResultsDiv&bu... (with trace logs).
> Distributed(Intermediate)SharedCacheFourNodesMapReduceTest randomly fails on Windows
> ------------------------------------------------------------------------------------
>
> Key: ISPN-4312
> URL: https://issues.jboss.org/browse/ISPN-4312
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Core
> Affects Versions: 7.0.0.Alpha4
> Environment: Windows machines, 2k8r2, 2k12r2
> Reporter: Tomas Sykora
> Assignee: Vladimir Blagojevic
> Priority: Blocker
> Labels: testsuite_stability
>
> It looks like tests have problems with fitting into 15 sec timeout on Windows.
> org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: Reduce phase executing at DistributedSharedCacheFourNodesMapReduceTest-NodeA-36515 did not complete within 15 sec timeout
> at org.infinispan.distexec.mapreduce.MapReduceTask.executeHelper(MapReduceTask.java:498)
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:447)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.testInvokeMapReduceOnAllKeysWithResultCache(BaseWordCountMapReduceTest.java:173)
> 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: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$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)
> Caused by: java.util.concurrent.ExecutionException: Reduce phase executing at DistributedSharedCacheFourNodesMapReduceTest-NodeA-36515 did not complete within 15 sec timeout
> at org.infinispan.distexec.mapreduce.MapReduceTask.executeReducePhase(MapReduceTask.java:748)
> at org.infinispan.distexec.mapreduce.MapReduceTask.executeHelper(MapReduceTask.java:495)
> ... 23 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: Node DistributedSharedCacheFourNodesMapReduceTest-NodeD-54406 timed out
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:174)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:280)
> at org.infinispan.remoting.rpc.RpcManagerImpl$2.call(RpcManagerImpl.java:312)
> ... 5 more
> Caused by: org.jgroups.TimeoutException: timeout sending message to DistributedSharedCacheFourNodesMapReduceTest-NodeD-54406
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:419)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:349)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> ... 8 more
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months