[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ]
Anna Manukyan edited comment on ISPN-2835 at 2/20/13 10:52 AM:
---------------------------------------------------------------
In this case, your code - the createCacheManagers() method should look something like:
{code}
@Override
protected void createCacheManagers() throws Throwable {
ConfigurationBuilder builder = getDefaultClusteredCacheConfig(CacheMode.DIST_SYNC, true);
createCluster(builder, 4);
for(EmbeddedCacheManager obj : cacheManagers) {
((DefaultCacheManager) obj).startCache();
}
}
{code}
was (Author: amanukyan):
In this case, your code - the createCacheManagers() method should look something like:
{code}
@Override
@Override
protected void createCacheManagers() throws Throwable {
ConfigurationBuilder builder = getDefaultClusteredCacheConfig(CacheMode.DIST_SYNC, true);
createCluster(builder, 4);
for(EmbeddedCacheManager obj : cacheManagers) {
((DefaultCacheManager) obj).startCache();
}
}
{code}
> 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.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 Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ]
Anna Manukyan commented on ISPN-2835:
-------------------------------------
[~saturnism] if you mean the startCache() method of DefaultCacheManager, then it will work, because if you'll go to the source of that method, then you can see that it calls the same getCache() method which I was talking about.
But you need to call startCache() on all cacheManagers.
> 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.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-2756) Enabling/disabling RpcManager statistics via JMX doesn't work
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2756?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2756:
-----------------------------------------------
Anna Manukyan <amanukya(a)redhat.com> changed the Status of [bug 906236|https://bugzilla.redhat.com/show_bug.cgi?id=906236] from ON_QA to VERIFIED
> Enabling/disabling RpcManager statistics via JMX doesn't work
> -------------------------------------------------------------
>
> Key: ISPN-2756
> URL: https://issues.jboss.org/browse/ISPN-2756
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 5.2.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.2.0.Final
>
>
> The test RpcManagerMBeanTest.testEnableJmxStats tries to write to the "StatisticsEnabled" attribute but fails. The operation doesn't throw an exception, but it does log this WARN message:
> {noformat}
> 10:43:42,079 WARN (testng-RpcManagerMBeanTest:) [ResourceDMBean] ISPN000043: Exception while writing value for attribute statisticsEnabled
> java.lang.NullPointerException
> at org.infinispan.jmx.ResourceDMBean$InvokableSetterBasedMBeanAttributeInfo.invoke(ResourceDMBean.java:391)
> at org.infinispan.jmx.ResourceDMBean.setNamedAttribute(ResourceDMBean.java:325)
> at org.infinispan.jmx.ResourceDMBean.setAttribute(ResourceDMBean.java:212)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.setAttribute(DefaultMBeanServerInterceptor.java:746)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.setAttribute(JmxMBeanServer.java:729)
> at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:134)
> {noformat}
> Because statistics are still enabled, the test then fails with an assertion error:
> {noformat}
> 10:43:42,464 ERROR (testng-RpcManagerMBeanTest:) [UnitTestTestNGListener] Test testEnableJmxStats(org.infinispan.jmx.RpcManagerMBeanTest) failed.
> java.lang.AssertionError: expected [-1] but found [1]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:165)
> at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:138)
> {noformat}
--
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-2756) Enabling/disabling RpcManager statistics via JMX doesn't work
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2756?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2756:
-----------------------------------------------
Anna Manukyan <amanukya(a)redhat.com> made a comment on [bug 906236|https://bugzilla.redhat.com/show_bug.cgi?id=906236]
The issue is verified! Thanks :)
> Enabling/disabling RpcManager statistics via JMX doesn't work
> -------------------------------------------------------------
>
> Key: ISPN-2756
> URL: https://issues.jboss.org/browse/ISPN-2756
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 5.2.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.2.0.Final
>
>
> The test RpcManagerMBeanTest.testEnableJmxStats tries to write to the "StatisticsEnabled" attribute but fails. The operation doesn't throw an exception, but it does log this WARN message:
> {noformat}
> 10:43:42,079 WARN (testng-RpcManagerMBeanTest:) [ResourceDMBean] ISPN000043: Exception while writing value for attribute statisticsEnabled
> java.lang.NullPointerException
> at org.infinispan.jmx.ResourceDMBean$InvokableSetterBasedMBeanAttributeInfo.invoke(ResourceDMBean.java:391)
> at org.infinispan.jmx.ResourceDMBean.setNamedAttribute(ResourceDMBean.java:325)
> at org.infinispan.jmx.ResourceDMBean.setAttribute(ResourceDMBean.java:212)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.setAttribute(DefaultMBeanServerInterceptor.java:746)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.setAttribute(JmxMBeanServer.java:729)
> at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:134)
> {noformat}
> Because statistics are still enabled, the test then fails with an assertion error:
> {noformat}
> 10:43:42,464 ERROR (testng-RpcManagerMBeanTest:) [UnitTestTestNGListener] Test testEnableJmxStats(org.infinispan.jmx.RpcManagerMBeanTest) failed.
> java.lang.AssertionError: expected [-1] but found [1]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:165)
> at org.infinispan.jmx.RpcManagerMBeanTest.testEnableJmxStats(RpcManagerMBeanTest.java:138)
> {noformat}
--
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:
---------------------------------
@Anna - shouldn't calling "startCache(...)" work?
> 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.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-2827) rhq-plugin does not work anymore
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2827?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2827:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
thanks, integrated 5.2.x + master
> rhq-plugin does not work anymore
> --------------------------------
>
> Key: ISPN-2827
> URL: https://issues.jboss.org/browse/ISPN-2827
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 5.2.1.Final
> Environment: RHQ 4.6.0-SNAPSHOT Build-Nummer: 6917de4
> Linux
> Reporter: Stan Nowogrudski steam
> Assignee: Tristan Tarrant
> Fix For: 5.2.2.Final
>
>
> After update to ISPN 5.2.1 and RHQ plugin 5.2.1 final is RHQ plugin not working properly any more. By klicking on on of ISPN Cache MBeans on the JMX Servers tree in RHQ, the RHQ notifies about uncatched exception.
--
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 Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ]
Anna Manukyan edited comment on ISPN-2835 at 2/20/13 10:31 AM:
---------------------------------------------------------------
Hi Ray,
yes - but the thing is that, when you create CacheManagers (which is done by createCluster(..) method, then the default caches are not created yet, until you will not call getCache() on each of them. And while the getCache() is not called, the cache doesn't exist for each of the CacheManagers, which means that already created nodes doesn't see created CacheManagers.
You can see the api description for getCache() method:
{noformat}
/**
* Retrieves the default cache associated with this cache manager. Note that the default cache does not need to be
* explicitly created with {@link #createCache(String)} since it is automatically created lazily when first used.
*
* As such, this method is always guaranteed to return the default cache.
*
* @return the default cache.
*/
@Override
public <K, V> Cache<K, V> getCache() {
return getCache(DEFAULT_CACHE_NAME);
}
{noformat}
Before making any cache related actions, especially if you have a cluster, you should make sure that the cache on nodes is properly started and the cluster is formed.
was (Author: amanukyan):
Hi Ray,
yes - but the thing is that, when you create CacheManagers (which is done by createCluster(..) method, then the default caches are not created yet, until you will not call getCache() on each of them. And while the getCache() is not called, the cache doesn't exist for each of the CacheManagers, which means that already created nodes doesn't see created CacheManagers.
You can see the api description for getCache() method:
/**
* Retrieves the default cache associated with this cache manager. Note that the default cache does not need to be
* explicitly created with {@link #createCache(String)} since it is automatically created lazily when first used.
*
* As such, this method is always guaranteed to return the default cache.
*
* @return the default cache.
*/
@Override
public <K, V> Cache<K, V> getCache() {
return getCache(DEFAULT_CACHE_NAME);
}
Before making any cache related actions, especially if you have a cluster, you should make sure that the cache on nodes is properly started and the cluster is formed.
> 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.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 Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ]
Anna Manukyan edited comment on ISPN-2835 at 2/20/13 10:29 AM:
---------------------------------------------------------------
Hi Ray,
yes - but the thing is that, when you create CacheManagers (which is done by createCluster(..) method, then the default caches are not created yet, until you will not call getCache() on each of them. And while the getCache() is not called, the cache doesn't exist for each of the CacheManagers, which means that already created nodes doesn't see created CacheManagers.
You can see the api description for getCache() method:
/**
* Retrieves the default cache associated with this cache manager. Note that the default cache does not need to be
* explicitly created with {@link #createCache(String)} since it is automatically created lazily when first used.
*
* As such, this method is always guaranteed to return the default cache.
*
* @return the default cache.
*/
@Override
public <K, V> Cache<K, V> getCache() {
return getCache(DEFAULT_CACHE_NAME);
}
Before making any cache related actions, especially if you have a cluster, you should make sure that the cache on nodes is properly started and the cluster is formed.
was (Author: amanukyan):
Hi Ray,
yes - but the thing is that, when you create CacheManagers (which is done by createCluster(..) method, then the default caches are not created yet, until you will not call getCache() on each of them. And while the getCache() is not called, the cache doesn't exist for each of the CacheManagers, which means that already created nodes doesn't see created CacheManagers.
You can see the api description for getCache() method:
{quote}
/**
* Retrieves the default cache associated with this cache manager. Note that the default cache does not need to be
* explicitly created with {@link #createCache(String)} since it is automatically created lazily when first used.
*
* As such, this method is always guaranteed to return the default cache.
*
* @return the default cache.
*/
@Override
public <K, V> Cache<K, V> getCache() {
return getCache(DEFAULT_CACHE_NAME);
}
{quote}
Before making any cache related actions, especially if you have a cluster, you should make sure that the cache on nodes is properly started and the cluster is formed.
> 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.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 Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ]
Anna Manukyan commented on ISPN-2835:
-------------------------------------
Hi Ray,
yes - but the thing is that, when you create CacheManagers (which is done by createCluster(..) method, then the default caches are not created yet, until you will not call getCache() on each of them. And while the getCache() is not called, the cache doesn't exist for each of the CacheManagers, which means that already created nodes doesn't see created CacheManagers.
You can see the api description for getCache() method:
{quote}
/**
* Retrieves the default cache associated with this cache manager. Note that the default cache does not need to be
* explicitly created with {@link #createCache(String)} since it is automatically created lazily when first used.
* <p/>
* As such, this method is always guaranteed to return the default cache.
*
* @return the default cache.
*/
@Override
public <K, V> Cache<K, V> getCache() {
return getCache(DEFAULT_CACHE_NAME);
}
{quote}
Before making any cache related actions, especially if you have a cluster, you should make sure that the cache on nodes is properly started and the cluster is formed.
> 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.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 Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ]
Anna Manukyan edited comment on ISPN-2835 at 2/20/13 10:28 AM:
---------------------------------------------------------------
Hi Ray,
yes - but the thing is that, when you create CacheManagers (which is done by createCluster(..) method, then the default caches are not created yet, until you will not call getCache() on each of them. And while the getCache() is not called, the cache doesn't exist for each of the CacheManagers, which means that already created nodes doesn't see created CacheManagers.
You can see the api description for getCache() method:
{quote}
/**
* Retrieves the default cache associated with this cache manager. Note that the default cache does not need to be
* explicitly created with {@link #createCache(String)} since it is automatically created lazily when first used.
*
* As such, this method is always guaranteed to return the default cache.
*
* @return the default cache.
*/
@Override
public <K, V> Cache<K, V> getCache() {
return getCache(DEFAULT_CACHE_NAME);
}
{quote}
Before making any cache related actions, especially if you have a cluster, you should make sure that the cache on nodes is properly started and the cluster is formed.
was (Author: amanukyan):
Hi Ray,
yes - but the thing is that, when you create CacheManagers (which is done by createCluster(..) method, then the default caches are not created yet, until you will not call getCache() on each of them. And while the getCache() is not called, the cache doesn't exist for each of the CacheManagers, which means that already created nodes doesn't see created CacheManagers.
You can see the api description for getCache() method:
{quote}
/**
* Retrieves the default cache associated with this cache manager. Note that the default cache does not need to be
* explicitly created with {@link #createCache(String)} since it is automatically created lazily when first used.
* <p/>
* As such, this method is always guaranteed to return the default cache.
*
* @return the default cache.
*/
@Override
public <K, V> Cache<K, V> getCache() {
return getCache(DEFAULT_CACHE_NAME);
}
{quote}
Before making any cache related actions, especially if you have a cluster, you should make sure that the cache on nodes is properly started and the cluster is formed.
> 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.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