[JBoss JIRA] (ISPN-2409) DefaultExecutorService failoverExecution rethrows not the root cause of the failure
by Anna Manukyan (JIRA)
Anna Manukyan created ISPN-2409:
-----------------------------------
Summary: DefaultExecutorService failoverExecution rethrows not the root cause of the failure
Key: ISPN-2409
URL: https://issues.jboss.org/browse/ISPN-2409
Project: Infinispan
Issue Type: Bug
Components: Distributed Execution and Map/Reduce
Reporter: Anna Manukyan
Assignee: Vladimir Blagojevic
Hi,
in case if Exception is thrown in Callable/DistributedCallable during execution with DistributedExecutor, it often happens that the real root cause of the exception is not shown - rethrown, but the following exception appears (see below).
In this case, the the code maintenance becomes harder, as it is not visible what caused the issue.
The pull request for the reproduction is:
java.util.concurrent.ExecutionException: Failover execution failed
at org.infinispan.distexec.DefaultExecutorService$DistributedTaskPart.failoverExecution(DefaultExecutorService.java:839)
at org.infinispan.distexec.DefaultExecutorService$DistributedTaskPart.get(DefaultExecutorService.java:801)
at org.infinispan.distexec.DistributedExecutorTest.basicInvocation(DistributedExecutorTest.java:86)
at org.infinispan.cdi.test.distexec.DistributedExecutorCDITest.testInvocationException(DistributedExecutorCDITest.java:89)
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.MethodInvocationHelper$1.runTestMethod(MethodInvocationHelper.java:176)
at org.jboss.arquillian.testng.Arquillian$1.invoke(Arquillian.java:111)
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.protocol.local.LocalContainerMethodExecutor.invoke(LocalContainerMethodExecutor.java:50)
at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:130)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:117)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:82)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:68)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:54)
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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
at org.jboss.arquillian.testng.Arquillian.run(Arquillian.java:102)
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.invokeHookable(MethodInvocationHelper.java:189)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:666)
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.runSequentially(SuiteRunner.java:312)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:274)
at org.testng.SuiteRunner.run(SuiteRunner.java:223)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1039)
at org.testng.TestNG.runSuitesLocally(TestNG.java:964)
at org.testng.TestNG.run(TestNG.java:900)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:110)
at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106)
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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:113)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.Exception: Failover execution failed
... 108 more
Caused by: java.util.concurrent.ExecutionException: Failover execution failed
at org.infinispan.distexec.DefaultExecutorService$DistributedTaskPart.failoverExecution(DefaultExecutorService.java:839)
at org.infinispan.distexec.DefaultExecutorService$DistributedTaskPart.get(DefaultExecutorService.java:801)
at org.infinispan.distexec.DefaultExecutorService$DistributedTaskPart.failoverExecution(DefaultExecutorService.java:834)
... 107 more
Caused by: java.lang.Exception: Failover execution failed
... 110 more
Caused by: java.util.concurrent.ExecutionException: Failover execution failed
at org.infinispan.distexec.DefaultExecutorService$DistributedTaskPart.failoverExecution(DefaultExecutorService.java:836)
... 109 more
Caused by: java.lang.Exception: Failover execution failed
... 110 more
Caused by: java.util.concurrent.ExecutionException: org.infinispan.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
at java.util.concurrent.FutureTask.get(FutureTask.java:111)
at org.infinispan.distexec.DefaultExecutorService$DistributedTaskPart.get(DefaultExecutorService.java:798)
... 108 more
Caused by: org.infinispan.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)
at org.infinispan.util.Util.rewrapAsCacheException(Util.java:532)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:184)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:514)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:176)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:198)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:255)
at org.infinispan.remoting.rpc.RpcManagerImpl.access$000(RpcManagerImpl.java:81)
at org.infinispan.remoting.rpc.RpcManagerImpl$1.call(RpcManagerImpl.java:289)
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)
Caused by: java.lang.RuntimeException: Failure to marshal argument(s)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:278)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:296)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:177)
... 11 more
Caused by: org.infinispan.marshall.NotSerializableException: org.infinispan.CacheImpl
Caused by: an exception which occurred:
in field cache
in object org.infinispan.cdi.test.distexec.DistributedExecutorCDITest$DistributedCacheCallable@4c824d8
-> toString = org.infinispan.cdi.test.distexec.DistributedExecutorCDITest$DistributedCacheCallable@4c824d8
in object org.infinispan.commands.read.DistributedExecuteCommand@1f
-> toString = DistributedExecuteCommand{cache=Cache 'DistributedExecutorTest-DIST_SYNC'@DistributedExecutorCDITest-NodeA-37398, keys=[], callable=org.infinispan.cdi.test.distexec.DistributedExecutorCDITest$DistributedCacheCallable@4c824d8}
in object org.infinispan.commands.remote.SingleRpcCommand@e8fbe1d0
-> toString = SingleRpcCommand{cacheName='DistributedExecutorTest-DIST_SYNC', command=DistributedExecuteCommand{cache=Cache 'DistributedExecutorTest-DIST_SYNC'@DistributedExecutorCDITest-NodeA-37398, keys=[], callable=org.infinispan.cdi.test.distexec.DistributedExecutorCDITest$DistributedCacheCallable@4c824d8}}
--
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, 4 months
[JBoss JIRA] Created: (ISPN-1220) Add classloader hooks to cache listener events
by Paul Ferraro (JIRA)
Add classloader hooks to cache listener events
----------------------------------------------
Key: ISPN-1220
URL: https://issues.jboss.org/browse/ISPN-1220
Project: Infinispan
Issue Type: Enhancement
Components: Listeners
Affects Versions: 5.0.0.CR7
Reporter: Paul Ferraro
Assignee: Manik Surtani
This issue seeks to extend the classloading api changes made in ISPN-1096 to the Event API. Currently, cache listener events do not allow a classloader to be specified to perform any necessary deserialization triggered by the getKey(), getValue() methods. Can the event api be enhanced such that calls to getKey(), getValue() use a specific classloader?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (ISPN-1568) Clustered Query fail when hibernate search not fully initialized
by Mathieu Lachance (Created) (JIRA)
Clustered Query fail when hibernate search not fully initialized
----------------------------------------------------------------
Key: ISPN-1568
URL: https://issues.jboss.org/browse/ISPN-1568
Project: Infinispan
Issue Type: Bug
Components: Querying, RPC
Affects Versions: 5.1.0.BETA5
Reporter: Mathieu Lachance
Assignee: Sanne Grinovero
Hi,
I'm running into this issue when doing a clustered query in distribution mode :
org.infinispan.CacheException: org.hibernate.search.SearchException: Not a mapped entity (don't forget to add @Indexed): class com.XXX.Client
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:166)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:181)
at org.infinispan.query.clustered.ClusteredQueryInvoker.broadcast(ClusteredQueryInvoker.java:113)
at org.infinispan.query.clustered.ClusteredCacheQueryImpl.broadcastQuery(ClusteredCacheQueryImpl.java:115)
at org.infinispan.query.clustered.ClusteredCacheQueryImpl.iterator(ClusteredCacheQueryImpl.java:90)
at org.infinispan.query.impl.CacheQueryImpl.iterator(CacheQueryImpl.java:129)
at org.infinispan.query.clustered.ClusteredCacheQueryImpl.list(ClusteredCacheQueryImpl.java:133)
at com.XXX.DistributedCache.cacheQueryList(DistributedCache.java:313)
at com.XXX.DistributedCache.cacheQueryList(DistributedCache.java:274)
at com.XXX.ClientCache.getClientsByServerId(ClientCache.java:127)
at com.XXX.ClientManager.getClientsByServerId(ClientManager.java:157)
at com.XXX$PingClient.run(PlayerBll.java:890)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: org.hibernate.search.SearchException: Not a mapped entity (don't forget to add @Indexed): class com.XXX.Client
at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:549)
at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:493)
at org.hibernate.search.query.engine.impl.HSQueryImpl.queryDocumentExtractor(HSQueryImpl.java:292)
at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.perform(CQCreateEagerQuery.java:44)
at org.infinispan.query.clustered.ClusteredQueryCommand.perform(ClusteredQueryCommand.java:135)
at org.infinispan.query.clustered.ClusteredQueryCommand.perform(ClusteredQueryCommand.java:129)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:170)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:179)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithRetry(InboundInvocationHandlerImpl.java:208)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:156)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:162)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:141)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:447)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:354)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:230)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:556)
at org.jgroups.JChannel.up(JChannel.java:716)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:881)
at org.jgroups.protocols.pbcast.StreamingStateTransfer.up(StreamingStateTransfer.java:262)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
at org.jgroups.protocols.UNICAST.up(UNICAST.java:332)
at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:700)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:561)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:140)
at org.jgroups.protocols.FD.up(FD.java:273)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:284)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
at org.jgroups.protocols.Discovery.up(Discovery.java:354)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1174)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1709)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1691)
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)
With the use of the following
cache configuration :
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:5.1 http://www.infinispan.org/schemas/infinispan-config-5.1.xsd"
xmlns="urn:infinispan:config:5.1">
<global>
<transport clusterName="XXX-cluster" machineId="XXX" siteId="XXX" rackId="XXX" distributedSyncTimeout="15000">
<properties>
<property name="configurationFile" value="jgroups-jdbc-ping.xml" />
</properties>
</transport>
</global>
<default>
<transaction
cacheStopTimeout="30000"
transactionManagerLookupClass="org.infinispan.transaction.lookup.DummyTransactionManagerLookup"
lockingMode="PESSIMISTIC"
useSynchronization="true"
transactionMode="TRANSACTIONAL"
syncCommitPhase="true"
syncRollbackPhase="false"
>
<recovery enabled="false" />
</transaction>
<clustering mode="local" />
<indexing enabled="true" indexLocalOnly="true">
<properties>
<property name="hibernate.search.default.directory_provider" value="ram" />
</properties>
</indexing>
</default>
<namedCache name="XXX-Client">
<transaction
cacheStopTimeout="30000"
transactionManagerLookupClass="org.infinispan.transaction.lookup.DummyTransactionManagerLookup"
lockingMode="PESSIMISTIC"
useSynchronization="true"
transactionMode="TRANSACTIONAL"
syncCommitPhase="true"
syncRollbackPhase="false"
>
<recovery enabled="false" />
</transaction>
<invocationBatching enabled="false" />
<loaders passivation="false" />
<clustering mode="distribution" >
<sync replTimeout="15000" />
<stateRetrieval
timeout="240000"
retryWaitTimeIncreaseFactor="2"
numRetries="5"
maxNonProgressingLogWrites="100"
fetchInMemoryState="false"
logFlushTimeout="60000"
alwaysProvideInMemoryState="false"
/>
</clustering>
<storeAsBinary enabled="false" storeValuesAsBinary="true" storeKeysAsBinary="true" />
<deadlockDetection enabled="true" spinDuration="100" />
<eviction strategy="NONE" threadPolicy="PIGGYBACK" maxEntries="-1" />
<jmxStatistics enabled="true" />
<locking writeSkewCheck="false" lockAcquisitionTimeout="10000" isolationLevel="READ_COMMITTED" useLockStriping="false" concurrencyLevel="32" />
<expiration wakeUpInterval="60000" lifespan="-1" maxIdle="3000000" />
</namedCache>
</infinispan>
and jgroups configuration :
<config xmlns="urn:org:jgroups"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:jgroups file:schema/JGroups-3.0.xsd">
<TCP
bind_port="7800"
loopback="true"
port_range="30"
recv_buf_size="20000000"
send_buf_size="640000"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
enable_bundling="true"
use_send_queues="true"
sock_conn_timeout="300"
enable_diagnostics="false"
thread_pool.enabled="true"
thread_pool.min_threads="2"
thread_pool.max_threads="30"
thread_pool.keep_alive_time="5000"
thread_pool.queue_enabled="false"
thread_pool.queue_max_size="100"
thread_pool.rejection_policy="Discard"
oob_thread_pool.enabled="true"
oob_thread_pool.min_threads="2"
oob_thread_pool.max_threads="30"
oob_thread_pool.keep_alive_time="5000"
oob_thread_pool.queue_enabled="false"
oob_thread_pool.queue_max_size="100"
oob_thread_pool.rejection_policy="Discard"
/>
<JDBC_PING
connection_url="jdbc:jtds:sqlserver://XXX;databaseName=XXX"
connection_username="XXX"
connection_password="XXX"
connection_driver="net.sourceforge.jtds.jdbcx.JtdsDataSource"
initialize_sql=""
/>
<MERGE2 max_interval="30000"
min_interval="10000"/>
<FD_SOCK/>
<FD timeout="3000" max_tries="3"/>
<VERIFY_SUSPECT timeout="1500"/>
<pbcast.NAKACK
use_mcast_xmit="false"
retransmit_timeout="300,600,1200,2400,4800"
discard_delivered_msgs="false"/>
<UNICAST timeout="300,600,1200"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="400000"/>
<pbcast.STATE />
<pbcast.GMS print_local_addr="false" join_timeout="7000" view_bundling="true"/>
<UFC max_credits="2000000" min_threshold="0.10"/>
<MFC max_credits="2000000" min_threshold="0.10"/>
<FRAG2 frag_size="60000"/>
</config>
Tough my entity is well annotated.
Here's the steps to reproduce :
1. boot node A completly.
2. boot node B, make all caches start (DefaultCacheManager::startCaches(...)), then breakpoint just after.
3. on node A, do a clustered query.
4. node A fail because node b has not been fully initialized.
Here's how I do my query :
private CacheQuery getClusteredNonClusteredQuery(Query query)
{
CacheQuery cacheQuery;
if (useClusteredQuery)
{
cacheQuery = searchManager.getClusteredQuery(query, cacheValueClass);
}
else
{
cacheQuery = searchManager.getQuery(query, cacheValueClass);
}
return cacheQuery;
}
I've tried also without supplying any "cacheValueClass" without any success.
One ugly "workaround" I've found is, to as soon as possible in the application, to force the local insertion and removal of one dummy key and value to force initialization of the search manager like :
cache.getAdvancedCache().withFlags(Flag.CACHE_MODE_LOCAL).put("XXX", new Client("XXX");
cache.getAdvancedCache().withFlags(Flag.CACHE_MODE_LOCAL).remove("XXX");
Tough this technique won't still garanty me that any clustered query will occur before.
I think the issue this might as well be related to issue : ISPN-627 Provision to get Cache from CacheManager.
Any idea or workaround ? Do you think by just adding a try catch and return an empty list could "fix" the problem ?
Thanks a lot,
--
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, 4 months
[JBoss JIRA] (ISPN-2359) Query should not reindex cache entries on preload or activation
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-2359:
-------------------------------------
Summary: Query should not reindex cache entries on preload or activation
Key: ISPN-2359
URL: https://issues.jboss.org/browse/ISPN-2359
Project: Infinispan
Issue Type: Enhancement
Components: Querying
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Fix For: 5.2.0.Beta1
If a cache entry is returning to the Infinispan datacontainer after activation or preloading it should not be re-indexed.
Check also that passivation doesn't remove the entry from the index.
--
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, 4 months
[JBoss JIRA] (ISPN-1990) Preload sets the versions to null (repeatable read + write skew)
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-1990:
---------------------------------
Summary: Preload sets the versions to null (repeatable read + write skew)
Key: ISPN-1990
URL: https://issues.jboss.org/browse/ISPN-1990
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Environment: Java 6 (64bits)
Infinispan 5.2.0-SNAPSHOT
MacOS
Reporter: Pedro Ruivo
Assignee: Manik Surtani
I think I've spotted a issue when I use repeatable read with write skew check and I preload the cache.
I've made a test case to reproduce the bug. It can be found here [1].
The problem is that each keys preloaded is put in the container with version = null. When I try to commit a transaction, I get this exception:
java.lang.IllegalStateException: Entries cannot have null versions!
at
org.infinispan.container.entries.ClusteredRepeatableReadEntry.performWriteSkewCheck(ClusteredRepeatableReadEntry.java:44)
at
org.infinispan.transaction.WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions(WriteSkewHelper.java:81)
at
org.infinispan.interceptors.locking.ClusteringDependentLogic$AllNodesLogic.createNewVersionsAndCheckForWriteSkews(ClusteringDependentLogic.java:133)
at
org.infinispan.interceptors.VersionedEntryWrappingInterceptor.visitPrepareCommand(VersionedEntryWrappingInterceptor.java:64)
I think that all info is in the test case, but if you need something let
me know.
Cheers,
Pedro
[1]
https://github.com/pruivo/infinispan/blob/issue_1/core/src/test/java/org/...
--
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, 4 months
[JBoss JIRA] (ISPN-2459) Rollback not preceded by Prepare sent to remote site
by Radim Vansa (JIRA)
Radim Vansa created ISPN-2459:
---------------------------------
Summary: Rollback not preceded by Prepare sent to remote site
Key: ISPN-2459
URL: https://issues.jboss.org/browse/ISPN-2459
Project: Infinispan
Issue Type: Bug
Components: Cross-Site Replication, Transactions
Affects Versions: 5.2.0.Beta3
Reporter: Radim Vansa
Assignee: Mircea Markus
When a {{TransactionManager.rollback()}} is called under optimistic locking, the {{RollbackCommand}} is sent to the remote site with backup cache. This makes no sense as there are no changes to roll back, and furthermore, the command fails in the remote site as the transaction which is rolled back is not known:
{code}
05:37:00,727 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (Incoming-2,global,_edg-perf01-58034:LON) Problems invoking command SingleRpcCommand{cacheName='nycCache', command=RollbackCommand {gtx=GlobalTransaction:<c25cba86-1e90-e190-b101-155e93063c9c[T]>:5:local, cacheName='nycCache', topologyId=-1}}
org.infinispan.CacheException: Couldn't find a local transaction corresponding to remote transaction GlobalTransaction:<c25cba86-1e90-e190-b101-155e93063c9c[T]>:5:local
at org.infinispan.xsite.BackupReceiver$BackupCacheUpdater.completeTransaction(BackupReceiver.java:187)
at org.infinispan.xsite.BackupReceiver$BackupCacheUpdater.visitRollbackCommand(BackupReceiver.java:178)
at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:61)
at org.infinispan.xsite.BackupReceiver.handleRemoteCommand(BackupReceiver.java:76)
at org.infinispan.xsite.BackupReceiverRepositoryImpl.handleRemoteCommand(BackupReceiverRepositoryImpl.java:60)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromRemoteSite(CommandAwareRpcDispatcher.java:240)
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:670)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
at org.jgroups.protocols.relay.RELAY2.deliver(RELAY2.java:420)
at org.jgroups.protocols.relay.RELAY2.route(RELAY2.java:316)
at org.jgroups.protocols.relay.RELAY2.handleMessage(RELAY2.java:292)
at org.jgroups.protocols.relay.RELAY2.handleRelayMessage(RELAY2.java:272)
at org.jgroups.protocols.relay.Relayer$Bridge.receive(Relayer.java:214)
at org.jgroups.JChannel.invokeCallback(JChannel.java:712)
at org.jgroups.JChannel.up(JChannel.java:673)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
at org.jgroups.protocols.RSVP.up(RSVP.java:188)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
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.handleDataReceived(UNICAST2.java:769)
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:601)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
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$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{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, 4 months
[JBoss JIRA] (ISPN-2240) Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key
by Robert Stupp (JIRA)
Robert Stupp created ISPN-2240:
----------------------------------
Summary: Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key
Key: ISPN-2240
URL: https://issues.jboss.org/browse/ISPN-2240
Project: Infinispan
Issue Type: Bug
Components: Locking and Concurrency
Affects Versions: 5.1.6.FINAL
Reporter: Robert Stupp
Assignee: Mircea Markus
Attachments: somehow.zip
Hi,
I've encountered a lot of TimeoutExceptions just running a load test against an infinispan cluster.
I tracked down the reason and found out, that the code in org.infinispan.util.concurrent.locks.containers.AbstractPerEntryLockContainer#releaseLock() causes these superfluous TimeoutExceptions.
A small test case (which just prints out timeouts, too late timeouts and "paints" a lot of dots to the console - more dots/second on the console means better throughput ;-)
In a short test I extended the class ReentrantPerEntryLockContainer and changed the implementation of releaseLock() as follows:
{noformat}
public void releaseLock(Object lockOwner, Object key) {
ReentrantLock l = locks.get(key);
if (l != null) {
if (!l.isHeldByCurrentThread())
throw new IllegalStateException("Lock for [" + key + "] not held by current thread " + Thread.currentThread());
while (l.isHeldByCurrentThread())
unlock(l, lockOwner);
if (!l.hasQueuedThreads())
locks.remove(key);
}
else
throw new IllegalStateException("No lock for [" + key + ']');
}
{noformat}
The main improvement is that locks are not removed from the concurrent map as long as other threads are waiting on that lock.
If the lock is removed from the map while other threads are waiting for it, they may run into timeouts and force TimeoutExceptions to the client.
The above methods "paints more dots per second" - means: it gives a better throughput for concurrent accesses to the same key.
The re-implemented method should also fix some replication timeout exceptions.
Please, please add this to 5.1.7, if possible.
--
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, 4 months
[JBoss JIRA] (ISPN-2205) Design HotRod protocol version 1.2
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2205:
----------------------------------
Summary: Design HotRod protocol version 1.2
Key: ISPN-2205
URL: https://issues.jboss.org/browse/ISPN-2205
Project: Infinispan
Issue Type: Task
Components: Cache Server
Affects Versions: 5.2.0.ALPHA2
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Critical
Fix For: 5.2.0.FINAL
The consistent hash representation is changing in 5.2, and we need to modify the HotRod protocol to incorporate those changes. We preserved compatibility with 1.0/1.1 clients with a workaround on the server, but is not as efficient as it could be.
The new version could also incorporate fixes for older issues like ISPN-1293.
--
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, 4 months