[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2835:
--------------------------------
Labels: onboard (was: )
> 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
> Labels: onboard
> Fix For: 5.3.0.Beta2, 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
11 years, 1 month
[JBoss JIRA] (ISPN-2823) TransactionManagerLookup is silently ignored with invocation batching
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2823?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2823:
--------------------------------
Assignee: Tristan Tarrant (was: Mircea Markus)
> TransactionManagerLookup is silently ignored with invocation batching
> ---------------------------------------------------------------------
>
> Key: ISPN-2823
> URL: https://issues.jboss.org/browse/ISPN-2823
> Project: Infinispan
> Issue Type: Bug
> Components: Core API, Transactions
> Affects Versions: 5.2.0.Final, 5.2.1.Final
> Reporter: Jeremy Stone
> Assignee: Tristan Tarrant
> Fix For: 5.3.0.Final
>
> Attachments: infinispan_batch_tx.zip
>
>
> A configured TransactionManagerLookup is ignored when invocation batching is enabled.
> Attempts to put an entry into the cache are greeted with "java.lang.IllegalStateException: This is a tx cache!" despite the presence of an active transaction.
> This seems to make it impossible to use the Tree API, where invocation batch mode is mandatory, in a transactional environment.
--
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
11 years, 1 month
[JBoss JIRA] (ISPN-2710) Huge amount of OOB threads during performance test
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2710?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2710:
-------------------------------------
ISPN-2808 should have solved the problem of maxing out the OOB pool. Please give it a try with 5.3.
> Huge amount of OOB threads during performance test
> --------------------------------------------------
>
> Key: ISPN-2710
> URL: https://issues.jboss.org/browse/ISPN-2710
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.2.0.CR1
> Reporter: Robert Stupp
> Assignee: Mircea Markus
>
> While running our performance test (as described in ISPN-2240), two of the four servers are running at 80 to 100% CPU - while the others just run at 10%.
> Before that phenomenom a huge amount (several 100s) of threads has been created (all called {{OOB-xxxx}}.
> The performance test just reads cached data - there was no cache put operation at that time.
--
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
11 years, 1 month
[JBoss JIRA] (ISPN-1965) Some entries not available during view change
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-1965?page=com.atlassian.jira.plugin.... ]
Mircea Markus resolved ISPN-1965.
---------------------------------
Resolution: Rejected
we don't offer any consistency guarantees after partition healing.
> Some entries not available during view change
> ---------------------------------------------
>
> Key: ISPN-1965
> URL: https://issues.jboss.org/browse/ISPN-1965
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.1.3.FINAL
> Reporter: Michal Linhard
> Assignee: Dan Berindei
>
> In the 4 node, dist mode, num-owners=2, elasticity test
> http://www.qa.jboss.com/~mlinhard/hyperion/run44-elas-dist/
> there is a cca 90 sec period of time where clients get null responses to GET
> requests on entries that should exist in the cache.
> first occurence:
> hyperion1139.log 05:31:01,202 286.409
> last occurence:
> hyperion1135.log 05:32:45,441 390.648
> total occurence count: (in all 19 driver nodes)
> 152241
> (this doesn't mean it happens for 152K keys, because each key is retried after
> erroneous attempt)
> data doesn't seem to be lost, because these errors cease after a while and
> number of entries returns back to normal (see cache_entries.csv)
> this happens approximately in the period between node0001 is killed and cluster
> {node0002 - node0004} is formed (and shortly after).
--
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
11 years, 1 month
[JBoss JIRA] (ISPN-2863) org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest.testInvokeMapWithReduceExceptionPhaseInRemoteExecution
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2863?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-2863:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=915831, https://bugzilla.redhat.com/show_bug.cgi?id=960376 (was: https://bugzilla.redhat.com/show_bug.cgi?id=915831)
> org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest.testInvokeMapWithReduceExceptionPhaseInRemoteExecution
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2863
> URL: https://issues.jboss.org/browse/ISPN-2863
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Execution and Map/Reduce
> Affects Versions: 5.2.2.Final
> Environment: OracleJDK1.7, Solaris10Sparc x64
> Reporter: Vitalii Chepeliuk
> Assignee: Vladimir Blagojevic
> Labels: testsuite_stability
> Fix For: 5.3.0.Beta2
>
>
> Error Message
> Method SimpleTwoNodesMapReduceTest.testInvokeMapWithReduceExceptionPhaseInRemoteExecution()[pri:0, instance:org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest@794d1a90] should have thrown an exception of class org.infinispan.CacheException
> Stacktrace
> org.testng.TestException:
> Method SimpleTwoNodesMapReduceTest.testInvokeMapWithReduceExceptionPhaseInRemoteExecution()[pri:0, instance:org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest@794d1a90] should have thrown an exception of class org.infinispan.CacheException
> at org.testng.internal.Invoker.handleInvocationResults(Invoker.java:1518)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:764)
> 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:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Standard Output
> [testng-TopologyAwareTwoNodesMapReduceTest] Test testInvokeMapWithReduceExceptionPhaseInRemoteExecution(org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest) failed.
> 2013-02-25 15:13:34,026 ERROR [UnitTestTestNGListener] (testng-TopologyAwareTwoNodesMapReduceTest) Test testInvokeMapWithReduceExceptionPhaseInRemoteExecution(org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest) failed.
> org.testng.TestException:
> Method SimpleTwoNodesMapReduceTest.testInvokeMapWithReduceExceptionPhaseInRemoteExecution()[pri:0, instance:org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest@794d1a90] should have thrown an exception of class org.infinispan.CacheException
> at org.testng.internal.Invoker.handleInvocationResults(Invoker.java:1518)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:764)
> 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:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Test suite progress: tests succeeded: 1680, failed: 1, skipped: 0.
--
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
11 years, 1 month
[JBoss JIRA] (ISPN-2186) Coordinator tries to install new view after graceful shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2186?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2186:
-----------------------------------------------
Misha H. Ali <mhusnain(a)redhat.com> made a comment on [bug 854665|https://bugzilla.redhat.com/show_bug.cgi?id=854665]
Set flag to nominate this bug for 6.2 release notes.
> Coordinator tries to install new view after graceful shutdown
> -------------------------------------------------------------
>
> Key: ISPN-2186
> URL: https://issues.jboss.org/browse/ISPN-2186
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.1.6.FINAL
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Priority: Minor
> Labels: jdg, jdg6
> Fix For: 5.1.x
>
>
> This is not a serious problem, because so far the only thing I discoverd it causes is a superfluous debug level log message.
> This happened in elasticity tests with radargun,
> In these tests we go from 4 nodes to 8 and back to 4.
> See views installed:
> http://www.qa.jboss.com/~mlinhard/hyperion2/run218-radargun-08-elasticity...
> In this case, each time the node is shutdown it is the coordinator (I'm not sure whether this is accident or coordinators are picked by their seniority in the cluster)
> The shutdown is made gracefully via DefaultCacheManager.stop() and each time this happens I can see an attempt of CacheViewsManagerImpl to install a new view - which doesn't complete because the coordinator shuts down few moments later and the new view is really established by a new coordinator.
> Log from slave on node0003:
> {code}
> 02:37:32,737 INFO [org.radargun.stages.KillStage] (pool-1-thread-1) Tearing down cache wrapper.
> 02:38:02,752 WARN [org.infinispan.transaction.TransactionTable] (pool-1-thread-1) ISPN000100: Stopping, but there are 9 local transactions and 0 remote transactions that did not finish in time.
> 02:38:02,755 DEBUG [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-3,hyperion1098-55173) Installing new view CacheView{viewId=9, members=[hyperion1099-41789, hyperion1097-42149, hyperion1100-42888, hyperion1102-1099, hyperion1101-56019, hyperion1103-38655, hyperion1096-46484]} for cache x
> 02:38:04,279 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (pool-1-thread-1) ISPN000080: Disconnecting and closing JGroups Channel
> 02:38:04,641 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (pool-1-thread-1) ISPN000082: Stopping the RpcDispatcher
> 02:38:04,816 INFO [org.radargun.Slave] (pool-1-thread-1) Finished stage: KillStage {tearDown=true, productName='jdg60', useSmartClassLoading=true, slaveIndex=0, activeSlavesCount=8, totalSlavesCount=8, slaves=[0]}
> 02:38:04,817 INFO [org.radargun.Slave] (main) Ack successfully sent to the master
> {code}
--
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
11 years, 1 month
[JBoss JIRA] (ISPN-2198) Cluster with non-shared JDBC cache store has too much entries after node failure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2198?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2198:
-----------------------------------------------
Misha H. Ali <mhusnain(a)redhat.com> made a comment on [bug 847809|https://bugzilla.redhat.com/show_bug.cgi?id=847809]
Set flag to nominate for 6.2 release notes.
> Cluster with non-shared JDBC cache store has too much entries after node failure
> --------------------------------------------------------------------------------
>
> Key: ISPN-2198
> URL: https://issues.jboss.org/browse/ISPN-2198
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.1.5.FINAL
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
> Attachments: cache_entries.csv, logs.zip, sfout.txt
>
>
> In resilience test with 4-node cluster where one node is killed a weird situation appears. Before the node kill have this number of entries:
> 210602;215820;209400;203038 = 838860 entries
> After the kill the number of entries changes for a while:
> 210602;null;209400;203038
> 250602;null;269400;243038
> 290602;null;269400;273038
> 300602;null;289400;293038
> 300602;null;289400;293038
> 321218;null;296035;293038
> But then it stabilizes on
> 326899;null;305039;314165 = 946103 entries
> When the node02 is restarted it complains about duplicit entries:
> ERROR [org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore] (OOB-124,null) ISPN008024: Error while storing string key to database; key: '8Az4Ia2V5NzYzNDI=', buffer size of value: 1050 bytes: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '?8Az4Ia2V5NzYzNDI=' for key 'PRIMARY'
> Is this a bug or wrong configuration?
> Here is an excerpt from configuration (sorry for no formatting):
> <distributed-cache batching="false" indexing="NONE" l1-lifespan="0" mode="SYNC" name="memcachedCache" owners="2" remote-timeout="60000" start="EAGER" virtual-nodes="512">
> <locking acquire-timeout="3000" concurrency-level="1000" isolation="REPEATABLE_READ" striping="false"/>
> <transaction mode="NONE"/>
> <state-transfer enabled="true" timeout="600000"/>
> <eviction max-entries="-1" strategy="NONE"/>
> <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" passivation="false" preload="false" purge="true" shared="false">
> <property name="databaseType">MYSQL</property>
> <string-keyed-table prefix="node01">
> <id-column name="id" type="VARCHAR(100)"/>
> <data-column name="value" type="BLOB(1200)"/>
> </string-keyed-table>
> </string-keyed-jdbc-store>
> </distributed-cache>
--
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
11 years, 1 month