[JBoss JIRA] (ISPN-2407) StateProviderImpl.getTransactionsForSegments can fail with an IllegalStateException
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2407:
----------------------------------
Summary: StateProviderImpl.getTransactionsForSegments can fail with an IllegalStateException
Key: ISPN-2407
URL: https://issues.jboss.org/browse/ISPN-2407
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.2.0.Beta2
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Critical
Fix For: 5.2.0.CR1
I have seen this in NoRpcOnReadonlyTransactionsTest:
{noformat}
18:07:58,765 TRACE (OOB-2,ISPN,NodeE-8639:a) [StateProviderImpl] Transactions were requested by node NodeF-33213 with topology 3, greater than the local topology (1). Waiting for topology 3 to be installed locally.
18:07:58,765 TRACE (OOB-2,ISPN,NodeE-8639:) [InboundInvocationHandlerImpl] Exception executing command
java.lang.IllegalArgumentException: Node NodeE-8639 is not a member
at org.infinispan.distribution.ch.DefaultConsistentHash.getSegmentsForOwner(DefaultConsistentHash.java:97)
at org.infinispan.statetransfer.StateProviderImpl.getTransactionsForSegments(StateProviderImpl.java:203)
at org.infinispan.statetransfer.StateRequestCommand.perform(StateRequestCommand.java:88)
{noformat}
The problem is that {{StateProviderImpl.getSegmentsForOwner}} uses an older consistent hash "cached" in StateProviderImpl, but the topology id in StateTransferLockImpl has been already updated by {{StateConsumerImpl.onTopologyUpdate}}, so calling {{StateTransferLockImpl.waitForTopology}} doesn't do anything.
The simplest solution would be to call {{StateProviderImpl.onTopologyUpdate}} before {{StateConsumerImpl.onTopologyUpdate}}, and it doesn't look like it would cause any problems.
--
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, 6 months
[JBoss JIRA] (ISPN-2386) MapReduce on custom classes doesn't work in case of CacheLoader
by Anna Manukyan (JIRA)
Anna Manukyan created ISPN-2386:
-----------------------------------
Summary: MapReduce on custom classes doesn't work in case of CacheLoader
Key: ISPN-2386
URL: https://issues.jboss.org/browse/ISPN-2386
Project: Infinispan
Issue Type: Bug
Components: Distributed Execution and Map/Reduce
Affects Versions: 5.2.0.Beta1
Reporter: Anna Manukyan
Assignee: Vladimir Blagojevic
The issue described in ISPN-2138 reappears in case when the cache is configured with CacheLoader.
The ClassCastException is thrown when MapReduce processes the entries from CacheLoader.
The Exception is:
java.lang.ClassCastException: org.infinispan.marshall.MarshalledValue cannot be cast to org.infinispan.distexec.mapreduce.Book
at org.infinispan.distexec.mapreduce.BookSearchTest$TitleBookSearcher.map(BookSearchTest.java:74)
at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.map(MapReduceManagerImpl.java:179)
at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForLocalReduction(MapReduceManagerImpl.java:87)
at org.infinispan.commands.read.MapCombineCommand.perform(MapCombineCommand.java:91)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:110)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:82)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:244)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:217)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:604)
at org.jgroups.JChannel.up(JChannel.java:715)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
at org.jgroups.protocols.FC.up(FC.java:479)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432)
at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:722)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:570)
at org.jgroups.protocols.Discovery.up(Discovery.java:359)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1293)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1856)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1829)
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)
I'll provide the pull request URL with reproduction/verification test later.
--
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, 6 months
[JBoss JIRA] (ISPN-2138) Could not execute MapReduce on AS7.1.1 getting java.lang.ClassCastException: org.infinispan.marshall.MarshalledValue
by Sandro Sonntag (JIRA)
Sandro Sonntag created ISPN-2138:
------------------------------------
Summary: Could not execute MapReduce on AS7.1.1 getting java.lang.ClassCastException: org.infinispan.marshall.MarshalledValue
Key: ISPN-2138
URL: https://issues.jboss.org/browse/ISPN-2138
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.5.FINAL
Reporter: Sandro Sonntag
Assignee: Manik Surtani
Priority: Blocker
If I execute a MapReduce Task in AS7 a ClassCastEx occurs in the Mapper.
Thanks for help.
~Sandro
java.lang.ClassCastException: org.infinispan.marshall.MarshalledValue cannot be cast to de.adorsys.fireonec2.server.PrimeStats
de.adorsys.fireonec2.server.PrimeCountMapper.map(PrimeCountMapper.java:10)
org.infinispan.commands.read.MapReduceCommand.perform(MapReduceCommand.java:144)
org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:285)
org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:358)
de.adorsys.fireonec2.server.StatsService.map(StatsService.java:44)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsIntercep
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (ISPN-2449) 5.1.x and 5.2.x API differences
by Randall Hauch (JIRA)
Randall Hauch created ISPN-2449:
-----------------------------------
Summary: 5.1.x and 5.2.x API differences
Key: ISPN-2449
URL: https://issues.jboss.org/browse/ISPN-2449
Project: Infinispan
Issue Type: Bug
Components: Configuration
Affects Versions: 5.2.0.Beta2
Reporter: Randall Hauch
Assignee: Mircea Markus
Priority: Minor
Programmatically configuring a cache store in 5.1.x makes use of the LoaderConfigurationBuilder:
{code:java}
LoaderConfigurationBuilder lb = configurationBuilder.loaders().addCacheLoader().cacheLoader(new JdbcBinaryCacheStore());
lb.addProperty("dropTableOnExit", "false")
.addProperty("createTableOnStart", "true")
.addProperty("connectionFactoryClass", "org.infinispan.loaders.jdbc.connectionfactory.PooledConnectionFactory")
.addProperty("connectionUrl", "jdbc:h2:file:/abs/path/string_based_db;DB_CLOSE_DELAY=1")
.addProperty("driverClass", "org.h2.Driver")
.addProperty("userName", "sa")
.addProperty("idColumnName", "ID_COLUMN")
.addProperty("idColumnType", "VARCHAR(255)")
.addProperty("timestampColumnName", "TIMESTAMP_COLUMN")
.addProperty("timestampColumnType", "BIGINT")
.addProperty("dataColumnName", "DATA_COLUMN")
.addProperty("dataColumnType", "BINARY")
.addProperty("bucketTableNamePrefix", "MODE")
.addProperty("cacheName", "default");
{code}
This code does not compile with 5.2.0.Beta2 because {{LoaderConfigurationBuilder}} now is parameterized by the type of LoaderConfiguration and builder, and the return type of {{addProperty(...)}} is {{LoaderConfigurationBuilder<T,S>}}. When the above 5.1.x-compatible code is used (as a raw type), the return type of {{addProperty(...)}} becomes {{Object}} and this breaks the fluent-API style code above.
For code that needs to compile against 5.1.x and 5.2.x, the workaround is to change the above code to remove the fluent-API usage:
{code:java}
LoaderConfigurationBuilder lb = configurationBuilder.loaders().addCacheLoader().cacheLoader(new JdbcBinaryCacheStore());
lb.addProperty("dropTableOnExit", "false");
lb.addProperty("createTableOnStart", "true");
lb.addProperty("connectionFactoryClass", "org.infinispan.loaders.jdbc.connectionfactory.PooledConnectionFactory");
lb.addProperty("connectionUrl", "jdbc:h2:file:/abs/path/string_based_db;DB_CLOSE_DELAY=1");
lb.addProperty("driverClass", "org.h2.Driver");
lb.addProperty("userName", "sa");
lb.addProperty("idColumnName", "ID_COLUMN");
lb.addProperty("idColumnType", "VARCHAR(255)");
lb.addProperty("timestampColumnName", "TIMESTAMP_COLUMN");
lb.addProperty("timestampColumnType", "BIGINT");
lb.addProperty("dataColumnName", "DATA_COLUMN");
lb.addProperty("dataColumnType", "BINARY");
lb.addProperty("bucketTableNamePrefix", "MODE");
lb.addProperty("cacheName", "default");
{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, 6 months
[JBoss JIRA] (ISPN-2451) DefaultExecutorService invokeAny(Collection tasks, long timeout, TimeUnit unit) waits till the task execution even if the timeout exceeds
by Anna Manukyan (JIRA)
Anna Manukyan created ISPN-2451:
-----------------------------------
Summary: DefaultExecutorService invokeAny(Collection tasks, long timeout, TimeUnit unit) waits till the task execution even if the timeout exceeds
Key: ISPN-2451
URL: https://issues.jboss.org/browse/ISPN-2451
Project: Infinispan
Issue Type: Bug
Reporter: Anna Manukyan
Assignee: Mircea Markus
Hi,
I've written some new tests for DefaultExecutorService for both testing the product as well as for increasing the coverage and I have some strange behaviour which I don't know whether related to concurency non-reliability or it is a bug.
I have a Callable which just sleeps for 10 seconds and the returns 1. And I have a test, which submits the callable to DefaultExecutorService with invokeAny(collection, timeout, TimeUnit) method, and passes as a parameter to the method 2 seconds. As far as I understand, this means that if the execution of any of the tasks will not complete in 2 seconds, the Timeout exception should be thrown.
But everytime I run the test, the TimeoutException is thrown only once maybe in 5 executions. The exception is:
org.testng.TestException:
Expected exception java.util.concurrent.TimeoutException but got org.testng.TestException:
Method org.infinispan.distexec.DistributedExecutorTest.testInvokeAnyTimedSleepingTasks() should have thrown an exception of class java.util.concurrent.TimeoutException
at org.testng.internal.Invoker.handleInvocationResults(Invoker.java:1416)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1184)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
at org.testng.TestRunner.privateRun(TestRunner.java:749)
at org.testng.TestRunner.run(TestRunner.java:600)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
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)
Caused by: org.testng.TestException:
Method org.infinispan.distexec.DistributedExecutorTest.testInvokeAnyTimedSleepingTasks() should have thrown an exception of class java.util.concurrent.TimeoutException
at org.testng.internal.Invoker.handleInvocationResults(Invoker.java:1442)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:722)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
... 12 more
You can find the test here:
https://github.com/andyuk1986/infinispan/blob/dist_exec_tests/core/src/te...
the test case is: testInvokeAnyTimedSleepingTasks()
--
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, 6 months
[JBoss JIRA] (ISPN-2443) DistributedTaskPart get(timeout, TimeUnit) throws ClassCastException in case the execution is not finished after specified time
by Anna Manukyan (JIRA)
Anna Manukyan created ISPN-2443:
-----------------------------------
Summary: DistributedTaskPart get(timeout, TimeUnit) throws ClassCastException in case the execution is not finished after specified time
Key: ISPN-2443
URL: https://issues.jboss.org/browse/ISPN-2443
Project: Infinispan
Issue Type: Bug
Components: Distributed Execution and Map/Reduce
Reporter: Anna Manukyan
Assignee: Vladimir Blagojevic
The issue appears almost every time the test is executed.
The case is the following:
1. Callable<Integer> is submitted to DistributedExecutorService for execution;
The callable body consists of simple Thread.sleep(i) which makes the callable to sleep for specific period of time.
2. Result is taken with get(long timeout, TimeUnit unit) method;
The timeout is given so that, it is much more shorter than the sleeping time of the callable. But sometimes it happens, that the get(timeout, unit) waits till the end. I guess this happens due to priority of threads.
3. In case of expected execution flow, i.e. if the method execution takes longer than the specified timeout, the following exception is thrown:
java.lang.ClassCastException: java.lang.Integer cannot be cast to java.util.Map
at org.infinispan.distexec.DefaultExecutorService$DistributedTaskPart.retrieveResult(DefaultExecutorService.java:882)
at org.infinispan.distexec.DefaultExecutorService$DistributedTaskPart.get(DefaultExecutorService.java:818)
at org.infinispan.distexec.DistributedExecutorTest.testSleepingCallableWithTimeoutOption(DistributedExecutorTest.java:336)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:673)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
at org.testng.TestRunner.privateRun(TestRunner.java:749)
at org.testng.TestRunner.run(TestRunner.java:600)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
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)
--
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, 6 months