[JBoss JIRA] (ISPN-4144) Cleanly shutdown intermediate M/R cache
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4144?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4144:
-------------------------------
Component/s: Core
Distributed Execution and Map/Reduce
> Cleanly shutdown intermediate M/R cache
> ---------------------------------------
>
> Key: ISPN-4144
> URL: https://issues.jboss.org/browse/ISPN-4144
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core, Distributed Execution and Map/Reduce
> Reporter: Vladimir Blagojevic
> Assignee: Dan Berindei
>
> For intermediate per task caches we simply remove that cache from cache manager. This operation is cluster wide but it still triggers rebalancing which in turn possibly creates logs that might raise false alarms for admins. Investigate if calling clear before removing cache from cache manager and/or disabling rebalancing for intermediate cache leads to a "cleaner" cache shutdown.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years
[JBoss JIRA] (ISPN-791) On node startup, ensure all peers have compatible configurations
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-791?page=com.atlassian.jira.plugin.s... ]
Dan Berindei updated ISPN-791:
------------------------------
Assignee: (was: Vladimir Blagojevic)
> On node startup, ensure all peers have compatible configurations
> ----------------------------------------------------------------
>
> Key: ISPN-791
> URL: https://issues.jboss.org/browse/ISPN-791
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Affects Versions: 4.1.0.Final
> Reporter: Manik Surtani
>
> This is to prevent caches that are supposed to be symmetric/identical from being misconfigured. Some elements are allowed to be unique, of course, such as bind addresses in JGroups as well as node names, server hints, certain props passed to cache stores, etc.
> A simple test could be a hash (MD5 or SHA1?) of the config XML (or a serial form of the generated Configuration bean) which is exchanged as a part of the join method. On failure of the hash check, the entire object could be checked, and if that fails as well, an appropriate ConfigurationException could be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years
[JBoss JIRA] (ISPN-2156) Benchmark and blog about a fast method of loading data into Infinispan
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2156?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2156:
-------------------------------
Assignee: (was: Vladimir Blagojevic)
> Benchmark and blog about a fast method of loading data into Infinispan
> ------------------------------------------------------------------------
>
> Key: ISPN-2156
> URL: https://issues.jboss.org/browse/ISPN-2156
> Project: Infinispan
> Issue Type: Task
> Components: Core, Documentation-Core
> Reporter: Mircea Markus
> Labels: docs
>
> To summarise:
> When using distributed caches, when we need to batch-load a set of data into the cluster inserting batches of keys that map to the same node should significantly increase the performance.
> Why?
> during the prepare phase each node receives the
> complete list of modifications in that transaction and not only the
> modification pertaining to it.
> E.g. say we have the following key->node mapping:
> {code}
> k1 -> A
> k2 -> B
> k3 -> C
> {code}
> Where k1, k2 and k3 are keys; A, B and C are nodes.
> If Tx1 writes (k1,k2,k3) then during the prepare A,B and C will receive
> the the same package containing all the modification - namely (k1,
> k2,k3). There are several reasons for doing this (apparently)
> unoptimized approach: serialize the prepare only once, better handling
> of recovery information.
> Now if you group transactions/batches base on key distribution the amount of redundant traffic is significantly reduced - and that translates in better performance especially when the datasets
> you're inserting is quite high.
> This JIRA is basically about benchmarking and blogging about this approach.
> A entry in the FAQ would be helpful as well.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years
[JBoss JIRA] (ISPN-3985) In BCHM traverse internal segments for parallel map/reduce execution
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3985?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3985:
-------------------------------
Fix Version/s: 7.1.0.Final
> In BCHM traverse internal segments for parallel map/reduce execution
> --------------------------------------------------------------------
>
> Key: ISPN-3985
> URL: https://issues.jboss.org/browse/ISPN-3985
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 7.0.0.Final
> Reporter: Vladimir Blagojevic
> Fix For: 7.1.0.Final
>
>
> Currently when BoundedConcurrentHashMap is used in DataContainer we split input keys and traverse key/value pairs in parallel using executor. That is all good, however, we should optimize this solution as each segment in BCHM is a separate map we can iterate over each segment in a separate thread rather than blindly splitting input keys.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years
[JBoss JIRA] (ISPN-3984) CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3984?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3984:
-------------------------------
Component/s: Core
Distributed Execution and Map/Reduce
> CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys random failures
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3984
> URL: https://issues.jboss.org/browse/ISPN-3984
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Distributed Execution and Map/Reduce, Test Suite - Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Assignee: Vladimir Blagojevic
> Labels: testsuite_stability
> Fix For: 7.1.0.Beta1
>
> Attachments: cmdtnmrt.log.gz
>
>
> The random failures in CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys seem to be caused by state transfer being disabled in the test's caches.
> {noformat}
> 12:11:51,674 ERROR (testng-CompatModeDistributedTwoNodesMapReduceTest:) [UnitTestTestNGListener] Test testInvokeMapReduceOnAllKeys(org.infinispan.distexec.mapreduce.CompatModeDistributedTwoNodesMapReduceTest) failed.
> java.lang.AssertionError: key 'well' does not have count 1 but 2
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.verifyResults(BaseWordCountMapReduceTest.java:224)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.verifyResults(BaseWordCountMapReduceTest.java:334)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.testInvokeMapReduceOnAllKeys(BaseWordCountMapReduceTest.java:162)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years
[JBoss JIRA] (ISPN-3984) CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3984?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3984:
-------------------------------
Assignee: (was: Vladimir Blagojevic)
> CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys random failures
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3984
> URL: https://issues.jboss.org/browse/ISPN-3984
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Distributed Execution and Map/Reduce, Test Suite - Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.1.0.Beta1
>
> Attachments: cmdtnmrt.log.gz
>
>
> The random failures in CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys seem to be caused by state transfer being disabled in the test's caches.
> {noformat}
> 12:11:51,674 ERROR (testng-CompatModeDistributedTwoNodesMapReduceTest:) [UnitTestTestNGListener] Test testInvokeMapReduceOnAllKeys(org.infinispan.distexec.mapreduce.CompatModeDistributedTwoNodesMapReduceTest) failed.
> java.lang.AssertionError: key 'well' does not have count 1 but 2
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.verifyResults(BaseWordCountMapReduceTest.java:224)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.verifyResults(BaseWordCountMapReduceTest.java:334)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.testInvokeMapReduceOnAllKeys(BaseWordCountMapReduceTest.java:162)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years