[JBoss JIRA] (ISPN-2837) Infinispan fails to compile
by Shadow Creeper (JIRA)
[ https://issues.jboss.org/browse/ISPN-2837?page=com.atlassian.jira.plugin.... ]
Shadow Creeper commented on ISPN-2837:
--------------------------------------
I have no idea why, but for some reason qualifying the package names in the default values of ManagedAttribute members allows successful build.
git diff based on 5.2.1.Final branch:
diff --git a/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java b/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java
index ee66a25..fcf8bbe 100644
--- a/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java
+++ b/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java
@@ -45,11 +45,11 @@
String displayName() default "";
- DataType dataType() default DataType.MEASUREMENT;
+ DataType dataType() default org.infinispan.jmx.annotations.DataType.MEASUREMENT;
- DisplayType displayType() default DisplayType.DETAIL;
+ DisplayType displayType() default org.infinispan.jmx.annotations.DisplayType.DETAIL;
- MeasurementType measurementType() default MeasurementType.DYNAMIC;
+ MeasurementType measurementType() default org.infinispan.jmx.annotations.MeasurementType.DYNAMIC;
- Units units() default Units.NONE;
+ Units units() default org.infinispan.jmx.annotations.Units.NONE;
}
> Infinispan fails to compile
> ---------------------------
>
> Key: ISPN-2837
> URL: https://issues.jboss.org/browse/ISPN-2837
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 5.2.0.CR3, 5.2.0.Final, 5.2.1.Final
> Environment: $ mvn --version
> Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
> Maven home: /home/me/bin/apache-maven-3.0.3
> Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.2.0-4-amd64", arch: "amd64", family: "unix"
> $ uname -a
> Linux myhost 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux
> Reporter: Shadow Creeper
> Assignee: Mircea Markus
> Labels: build, compile, errors, failure, maven, mvn
>
> The latest version of Infinispan which compiles for me is "5.2.0.CR2" all since then fail with the following errors building infinispan-core:
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.0:compile (default-compile) on project infinispan-core: Compilation failure: Compilation failure:
> [ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[48,40] incompatible types
> [ERROR] found : org.infinispan.jmx.annotations.DataType
> [ERROR] required: org.infinispan.jmx.annotations.DataType
> [ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[50,49] incompatible types
> [ERROR] found : org.infinispan.jmx.annotations.DisplayType
> [ERROR] required: org.infinispan.jmx.annotations.DisplayType
> [ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[52,61] incompatible types
> [ERROR] found : org.infinispan.jmx.annotations.MeasurementType
> [ERROR] required: org.infinispan.jmx.annotations.MeasurementType
> [ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[54,31] incompatible types
> [ERROR] found : org.infinispan.jmx.annotations.Units
> [ERROR] required: org.infinispan.jmx.annotations.Units
> [ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[48,40] incompatible types
> [ERROR] found : org.infinispan.jmx.annotations.DataType
> [ERROR] required: org.infinispan.jmx.annotations.DataType
> [ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[50,49] incompatible types
> [ERROR] found : org.infinispan.jmx.annotations.DisplayType
> [ERROR] required: org.infinispan.jmx.annotations.DisplayType
> [ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[52,61] incompatible types
> [ERROR] found : org.infinispan.jmx.annotations.MeasurementType
> [ERROR] required: org.infinispan.jmx.annotations.MeasurementType
> [ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[54,31] incompatible types
> [ERROR] found : org.infinispan.jmx.annotations.Units
> [ERROR] required: org.infinispan.jmx.annotations.Units
--
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
13 years, 1 month
[JBoss JIRA] (ISPN-2837) Infinispan fails to compile
by Shadow Creeper (JIRA)
Shadow Creeper created ISPN-2837:
------------------------------------
Summary: Infinispan fails to compile
Key: ISPN-2837
URL: https://issues.jboss.org/browse/ISPN-2837
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 5.2.1.Final, 5.2.0.Final, 5.2.0.CR3
Environment: $ mvn --version
Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
Maven home: /home/me/bin/apache-maven-3.0.3
Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.2.0-4-amd64", arch: "amd64", family: "unix"
$ uname -a
Linux myhost 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux
Reporter: Shadow Creeper
Assignee: Mircea Markus
The latest version of Infinispan which compiles for me is "5.2.0.CR2" all since then fail with the following errors building infinispan-core:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.0:compile (default-compile) on project infinispan-core: Compilation failure: Compilation failure:
[ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[48,40] incompatible types
[ERROR] found : org.infinispan.jmx.annotations.DataType
[ERROR] required: org.infinispan.jmx.annotations.DataType
[ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[50,49] incompatible types
[ERROR] found : org.infinispan.jmx.annotations.DisplayType
[ERROR] required: org.infinispan.jmx.annotations.DisplayType
[ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[52,61] incompatible types
[ERROR] found : org.infinispan.jmx.annotations.MeasurementType
[ERROR] required: org.infinispan.jmx.annotations.MeasurementType
[ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[54,31] incompatible types
[ERROR] found : org.infinispan.jmx.annotations.Units
[ERROR] required: org.infinispan.jmx.annotations.Units
[ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[48,40] incompatible types
[ERROR] found : org.infinispan.jmx.annotations.DataType
[ERROR] required: org.infinispan.jmx.annotations.DataType
[ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[50,49] incompatible types
[ERROR] found : org.infinispan.jmx.annotations.DisplayType
[ERROR] required: org.infinispan.jmx.annotations.DisplayType
[ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[52,61] incompatible types
[ERROR] found : org.infinispan.jmx.annotations.MeasurementType
[ERROR] required: org.infinispan.jmx.annotations.MeasurementType
[ERROR] /home/me/projects/infinispan-git/core/src/main/java/org/infinispan/jmx/annotations/ManagedAttribute.java:[54,31] incompatible types
[ERROR] found : org.infinispan.jmx.annotations.Units
[ERROR] required: org.infinispan.jmx.annotations.Units
--
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
13 years, 1 month
[JBoss JIRA] (ISPN-2836) Thread deadlock in Map/Reduce with 2 nodes
by Alan Field (JIRA)
[ https://issues.jboss.org/browse/ISPN-2836?page=com.atlassian.jira.plugin.... ]
Alan Field updated ISPN-2836:
-----------------------------
Attachment: afield-tcp-521-final.txt
udp-edg-perf01.txt
udp-edg-perf02.txt
TCP and UDP thread dumps
> Thread deadlock in Map/Reduce with 2 nodes
> ------------------------------------------
>
> Key: ISPN-2836
> URL: https://issues.jboss.org/browse/ISPN-2836
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Execution and Map/Reduce
> Affects Versions: 5.2.1.Final
> Reporter: Alan Field
> Assignee: Vladimir Blagojevic
> Attachments: afield-tcp-521-final.txt, udp-edg-perf01.txt, udp-edg-perf02.txt
>
>
> Using RadarGun and two nodes to execute the example WordCount Map/Reduce job against a cache with ~550 keys with a value size of 1MB is producing a thread deadlock. The cache is distributed with transactions disabled.
> TCP transport deadlocks without throwing an exception. Disabling the send queue and setting UNICAST2.conn_expiry_timeout=0 prevents the deadlock, but the job does not complete. The nodes send "are-you-alive" messages back and forth, and I have seen the following exception:
> {noformat}
> 11:44:29,970 ERROR [org.jgroups.protocols.TCP] (OOB-98,default,edg-perf01-1907) failed sending message to edg-perf02-32536 (76 bytes): java.net.SocketException: Socket closed, cause: null
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:352)
> at org.radargun.cachewrappers.InfinispanMapReduceWrapper.executeMapReduceTask(InfinispanMapReduceWrapper.java:98)
> at org.radargun.stages.MapReduceStage.executeOnSlave(MapReduceStage.java:74)
> at org.radargun.Slave$2.run(Slave.java:103)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> 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:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to edg-perf02-32536
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
> at java.util.concurrent.FutureTask.get(FutureTask.java:83)
> at org.infinispan.distexec.mapreduce.MapReduceTask$TaskPart.get(MapReduceTask.java:832)
> at org.infinispan.distexec.mapreduce.MapReduceTask.executeMapPhaseWithLocalReduction(MapReduceTask.java:477)
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:350)
> ... 9 more
> Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to edg-perf02-32536
> at org.infinispan.util.Util.rewrapAsCacheException(Util.java:541)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:186)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:515)
> 11:44:29,978 ERROR [org.jgroups.protocols.TCP] (Timer-3,default,edg-perf01-1907) failed sending message to edg-perf02-32536 (60 bytes): java.net.SocketException: Socket closed, cause: null
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:175)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:197)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:254)
> at org.infinispan.remoting.rpc.RpcManagerImpl.access$000(RpcManagerImpl.java:80)
> at org.infinispan.remoting.rpc.RpcManagerImpl$1.call(RpcManagerImpl.java:288)
> ... 5 more
> Caused by: org.jgroups.TimeoutException: timeout sending message to edg-perf02-32536
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:390)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:301)
> 11:44:29,979 ERROR [org.jgroups.protocols.TCP] (Timer-4,default,edg-perf01-1907) failed sending message to edg-perf02-32536 (63 bytes): java.net.SocketException: Socket closed, cause: null
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:179)
> ... 11 more
> {noformat}
> With UDP transport, both threads are deadlocked. I will attach thread dumps from runs using TCP and UDP transport.
--
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
13 years, 1 month
[JBoss JIRA] (ISPN-2836) Thread deadlock in Map/Reduce with 2 nodes
by Alan Field (JIRA)
Alan Field created ISPN-2836:
--------------------------------
Summary: Thread deadlock in Map/Reduce with 2 nodes
Key: ISPN-2836
URL: https://issues.jboss.org/browse/ISPN-2836
Project: Infinispan
Issue Type: Bug
Components: Distributed Execution and Map/Reduce
Affects Versions: 5.2.1.Final
Reporter: Alan Field
Assignee: Vladimir Blagojevic
Using RadarGun and two nodes to execute the example WordCount Map/Reduce job against a cache with ~550 keys with a value size of 1MB is producing a thread deadlock. The cache is distributed with transactions disabled.
TCP transport deadlocks without throwing an exception. Disabling the send queue and setting UNICAST2.conn_expiry_timeout=0 prevents the deadlock, but the job does not complete. The nodes send "are-you-alive" messages back and forth, and I have seen the following exception:
{noformat}
11:44:29,970 ERROR [org.jgroups.protocols.TCP] (OOB-98,default,edg-perf01-1907) failed sending message to edg-perf02-32536 (76 bytes): java.net.SocketException: Socket closed, cause: null
at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:352)
at org.radargun.cachewrappers.InfinispanMapReduceWrapper.executeMapReduceTask(InfinispanMapReduceWrapper.java:98)
at org.radargun.stages.MapReduceStage.executeOnSlave(MapReduceStage.java:74)
at org.radargun.Slave$2.run(Slave.java:103)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
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:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to edg-perf02-32536
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at org.infinispan.distexec.mapreduce.MapReduceTask$TaskPart.get(MapReduceTask.java:832)
at org.infinispan.distexec.mapreduce.MapReduceTask.executeMapPhaseWithLocalReduction(MapReduceTask.java:477)
at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:350)
... 9 more
Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to edg-perf02-32536
at org.infinispan.util.Util.rewrapAsCacheException(Util.java:541)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:186)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:515)
11:44:29,978 ERROR [org.jgroups.protocols.TCP] (Timer-3,default,edg-perf01-1907) failed sending message to edg-perf02-32536 (60 bytes): java.net.SocketException: Socket closed, cause: null
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:175)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:197)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:254)
at org.infinispan.remoting.rpc.RpcManagerImpl.access$000(RpcManagerImpl.java:80)
at org.infinispan.remoting.rpc.RpcManagerImpl$1.call(RpcManagerImpl.java:288)
... 5 more
Caused by: org.jgroups.TimeoutException: timeout sending message to edg-perf02-32536
at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:390)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:301)
11:44:29,979 ERROR [org.jgroups.protocols.TCP] (Timer-4,default,edg-perf01-1907) failed sending message to edg-perf02-32536 (63 bytes): java.net.SocketException: Socket closed, cause: null
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:179)
... 11 more
{noformat}
With UDP transport, both threads are deadlocked. I will attach thread dumps from runs using TCP and UDP transport.
--
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
13 years, 1 month
[JBoss JIRA] (ISPN-825) Consider staggering remote get requests when using DIST
by Manik Surtani (JIRA)
[ https://issues.jboss.org/browse/ISPN-825?page=com.atlassian.jira.plugin.s... ]
Manik Surtani commented on ISPN-825:
------------------------------------
My working branch containing this fix: https://github.com/maniksurtani/infinispan/tree/t_825
> Consider staggering remote get requests when using DIST
> -------------------------------------------------------
>
> Key: ISPN-825
> URL: https://issues.jboss.org/browse/ISPN-825
> Project: Infinispan
> Issue Type: Feature Request
> Components: RPC
> Affects Versions: 4.1.0.Final
> Reporter: Manik Surtani
> Assignee: Mircea Markus
> Priority: Critical
> Labels: optimization, performance
> Fix For: 5.3.0.Final
>
>
> In DIST mode, when a request is made on a key that is not mapped locally, a remote get is sent to all data owners of that key and the first response is used. This can add unnecessary load on the network as all nodes still eventually respond, and if values are large this can cause a lot of unnecessary network traffic.
> The purpose of broadcasting to all data owners is so that (1) if one is down, another could still respond (2) if one is overloaded, others may respond faster.
> A solution around this could be based on either (or both) of:
> * Provide a configurable stagger timeout, e.g. 100ms. E.g., RPC to (random) Owner1. Wait for timeout t. If no response, RPC to Owner2. etc.
> * Always broadcast to a (configurable) subset of owners, e.g., always 2 even if numOwners is 5.
> Needs careful thought and design.
--
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
13 years, 1 month
[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes
by Ray Tsang (JIRA)
[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ]
Ray Tsang commented on ISPN-2835:
---------------------------------
I should note - simply calling startCache(...) didn't seem to work either. getCache() needed to be called first.
> Issues w/ M/R test cases if cache are not explicitly started on all nodes
> -------------------------------------------------------------------------
>
> Key: ISPN-2835
> URL: https://issues.jboss.org/browse/ISPN-2835
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API, Distributed Execution and Map/Reduce
> Reporter: Ray Tsang
> Assignee: Galder Zamarreño
> Fix For: 5.2.2.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: mr-test-src.zip
>
>
> I ran into some issues while using M/R. The gist of the issue I was seeing is that:
> Start a cluster of Embedded Caches, like 4 nodes
> Put in 100 elements
> Run a simple M/R job to count the number of keys
> If I run the M/R job using the node I'm inserting elements into as coordinator - the result is 100
> But if I run the M/R job using a different node as coordinator, the result is less than 100
> More interestingly, I can pause for 5 seconds and run the M/R jobs again, the results are always less than 100
> This behavior doens't occur if I explicitly run cacheManager.getCache() for each of 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
13 years, 1 month
[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2835:
-----------------------------------
Component/s: Distributed Execution and Map/Reduce
> Issues w/ M/R test cases if cache are not explicitly started on all nodes
> -------------------------------------------------------------------------
>
> Key: ISPN-2835
> URL: https://issues.jboss.org/browse/ISPN-2835
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API, Distributed Execution and Map/Reduce
> Reporter: Ray Tsang
> Assignee: Galder Zamarreño
> Fix For: 5.2.2.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: mr-test-src.zip
>
>
> I ran into some issues while using M/R. The gist of the issue I was seeing is that:
> Start a cluster of Embedded Caches, like 4 nodes
> Put in 100 elements
> Run a simple M/R job to count the number of keys
> If I run the M/R job using the node I'm inserting elements into as coordinator - the result is 100
> But if I run the M/R job using a different node as coordinator, the result is less than 100
> More interestingly, I can pause for 5 seconds and run the M/R jobs again, the results are always less than 100
> This behavior doens't occur if I explicitly run cacheManager.getCache() for each of 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
13 years, 1 month
[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2835:
-----------------------------------
Fix Version/s: 5.2.2.Final
5.3.0.Alpha1
5.3.0.Final
> Issues w/ M/R test cases if cache are not explicitly started on all nodes
> -------------------------------------------------------------------------
>
> Key: ISPN-2835
> URL: https://issues.jboss.org/browse/ISPN-2835
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Reporter: Ray Tsang
> Assignee: Galder Zamarreño
> Fix For: 5.2.2.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: mr-test-src.zip
>
>
> I ran into some issues while using M/R. The gist of the issue I was seeing is that:
> Start a cluster of Embedded Caches, like 4 nodes
> Put in 100 elements
> Run a simple M/R job to count the number of keys
> If I run the M/R job using the node I'm inserting elements into as coordinator - the result is 100
> But if I run the M/R job using a different node as coordinator, the result is less than 100
> More interestingly, I can pause for 5 seconds and run the M/R jobs again, the results are always less than 100
> This behavior doens't occur if I explicitly run cacheManager.getCache() for each of 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
13 years, 1 month
[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes
by Ray Tsang (JIRA)
Ray Tsang created ISPN-2835:
-------------------------------
Summary: Issues w/ M/R test cases if cache are not explicitly started on all nodes
Key: ISPN-2835
URL: https://issues.jboss.org/browse/ISPN-2835
Project: Infinispan
Issue Type: Feature Request
Components: Core API
Reporter: Ray Tsang
Assignee: Galder Zamarreño
Attachments: mr-test-src.zip
I ran into some issues while using M/R. The gist of the issue I was seeing is that:
Start a cluster of Embedded Caches, like 4 nodes
Put in 100 elements
Run a simple M/R job to count the number of keys
If I run the M/R job using the node I'm inserting elements into as coordinator - the result is 100
But if I run the M/R job using a different node as coordinator, the result is less than 100
More interestingly, I can pause for 5 seconds and run the M/R jobs again, the results are always less than 100
This behavior doens't occur if I explicitly run cacheManager.getCache() for each of 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
13 years, 1 month
[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes
by Ray Tsang (JIRA)
[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ]
Ray Tsang updated ISPN-2835:
----------------------------
Attachment: mr-test-src.zip
mvn -Dtest=*MapReduce* test
> Issues w/ M/R test cases if cache are not explicitly started on all nodes
> -------------------------------------------------------------------------
>
> Key: ISPN-2835
> URL: https://issues.jboss.org/browse/ISPN-2835
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Reporter: Ray Tsang
> Assignee: Galder Zamarreño
> Attachments: mr-test-src.zip
>
>
> I ran into some issues while using M/R. The gist of the issue I was seeing is that:
> Start a cluster of Embedded Caches, like 4 nodes
> Put in 100 elements
> Run a simple M/R job to count the number of keys
> If I run the M/R job using the node I'm inserting elements into as coordinator - the result is 100
> But if I run the M/R job using a different node as coordinator, the result is less than 100
> More interestingly, I can pause for 5 seconds and run the M/R jobs again, the results are always less than 100
> This behavior doens't occur if I explicitly run cacheManager.getCache() for each of 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
13 years, 1 month