[JBoss JIRA] (ISPN-2773) Can't access a non-clustered cache via HotRod
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2773:
----------------------------------
Summary: Can't access a non-clustered cache via HotRod
Key: ISPN-2773
URL: https://issues.jboss.org/browse/ISPN-2773
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 5.2.0.CR3
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Blocker
Fix For: 5.2.0.Final
With the ISPN-2632 fix, we switched from using the JGroups view id as a HotRod topology id, to using the topology id of the cache being accessed.
If the cache isn't clustered, however, it doesn't have a RpcManager and attempting to read the cache's topology id results in a NullPointerException:
{noformat}
java.lang.NullPointerException
at org.infinispan.server.hotrod.AbstractEncoder1x.getTopologyResponse(AbstractEncoder1x.scala:160)
at org.infinispan.server.hotrod.AbstractEncoder1x.writeHeader(AbstractEncoder1x.scala:49)
at org.infinispan.server.hotrod.HotRodEncoder.encode(HotRodEncoder.scala:63)
at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:66)
at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59)
at org.jboss.netty.channel.Channels.write(Channels.java:704)
at org.jboss.netty.channel.Channels.write(Channels.java:671)
at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248)
at org.infinispan.server.core.AbstractProtocolDecoder.writeResponse(AbstractProtocolDecoder.scala:179)
at org.infinispan.server.hotrod.HotRodDecoder.customDecodeHeader(HotRodDecoder.scala:157)
at org.infinispan.server.core.AbstractProtocolDecoder.decodeHeader(AbstractProtocolDecoder.scala:105)
at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:70)
at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:47)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435)
at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:387)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107)
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:313)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
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)
{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
11 years, 11 months
[JBoss JIRA] (ISPN-2772) Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2772?page=com.atlassian.jira.plugin.... ]
Mircea Markus edited comment on ISPN-2772 at 1/29/13 2:04 PM:
--------------------------------------------------------------
The logic for automatically switching from JGroups' anycast to JGroups' multicast is already implemented for L1 invalidation[1], so we can reuse it (see L1ManagrImpl.isUseMulticast and its usages).
was (Author: mircea.markus):
The logic for automatically switching from JGroups' anycast to JGroups' multicast is already implemented for L1 invalidation[1], so we can reuse it.
[1] https://github.com/mmarkus/infinispan/blob/master/core/src/main/java/org/...
> Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
> ------------------------------------------------------------------------------------
>
> Key: ISPN-2772
> URL: https://issues.jboss.org/browse/ISPN-2772
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.2.0.Final
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 5.3.0.Final
>
>
> This has already been done in the case of state transfer, where the distribution state transfer code is reused for replicated caches as well.
> The main reason behind this improvement is to simplify/reduce the code. Also there will be some additional benefits:
> - ATM in replicated mode, the JGroups coordinator always plays the role of main lock owner. The coordinator might get overwhelmed as it has to process the additional TxCompletionNotificationCommand on every transaction (direct consequence of being main lock owner). OTOH in distributed mode, the lock owner is spread between the cluster members.
> As an optimisation, on REPL mode, we can use multicasting (when on UDP) for message sending.
--
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, 11 months
[JBoss JIRA] (ISPN-2772) Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2772?page=com.atlassian.jira.plugin.... ]
Mircea Markus edited comment on ISPN-2772 at 1/29/13 2:04 PM:
--------------------------------------------------------------
The logic for automatically switching from JGroups' anycast to JGroups' multicast is already implemented for L1 invalidation, so we can reuse it (see L1ManagrImpl.isUseMulticast and its usages).
was (Author: mircea.markus):
The logic for automatically switching from JGroups' anycast to JGroups' multicast is already implemented for L1 invalidation[1], so we can reuse it (see L1ManagrImpl.isUseMulticast and its usages).
> Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
> ------------------------------------------------------------------------------------
>
> Key: ISPN-2772
> URL: https://issues.jboss.org/browse/ISPN-2772
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.2.0.Final
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 5.3.0.Final
>
>
> This has already been done in the case of state transfer, where the distribution state transfer code is reused for replicated caches as well.
> The main reason behind this improvement is to simplify/reduce the code. Also there will be some additional benefits:
> - ATM in replicated mode, the JGroups coordinator always plays the role of main lock owner. The coordinator might get overwhelmed as it has to process the additional TxCompletionNotificationCommand on every transaction (direct consequence of being main lock owner). OTOH in distributed mode, the lock owner is spread between the cluster members.
> As an optimisation, on REPL mode, we can use multicasting (when on UDP) for message sending.
--
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, 11 months
[JBoss JIRA] (ISPN-2772) Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2772?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2772:
-------------------------------------
The logic for automatically switching from JGroups' anycast to JGroups' multicast is already implemented for L1 invalidation[1], so we can reuse it.
[1] https://github.com/mmarkus/infinispan/blob/master/core/src/main/java/org/...
> Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
> ------------------------------------------------------------------------------------
>
> Key: ISPN-2772
> URL: https://issues.jboss.org/browse/ISPN-2772
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.2.0.Final
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 5.3.0.Final
>
>
> This has already been done in the case of state transfer, where the distribution state transfer code is reused for replicated caches as well.
> The main reason behind this improvement is to simplify/reduce the code. Also there will be some additional benefits:
> - ATM in replicated mode, the JGroups coordinator always plays the role of main lock owner. The coordinator might get overwhelmed as it has to process the additional TxCompletionNotificationCommand on every transaction (direct consequence of being main lock owner). OTOH in distributed mode, the lock owner is spread between the cluster members.
> As an optimisation, on REPL mode, we can use multicasting (when on UDP) for message sending.
--
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, 11 months
[JBoss JIRA] (ISPN-2772) Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
by Mircea Markus (JIRA)
Mircea Markus created ISPN-2772:
-----------------------------------
Summary: Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize)
Key: ISPN-2772
URL: https://issues.jboss.org/browse/ISPN-2772
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.2.0.Final
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 5.3.0.Final
This has already been done in the case of state transfer, where the distribution state transfer code is reused for replicated caches as well.
The main reason behind this improvement is to simplify/reduce the code. Also there will be some additional benefits:
- ATM in replicated mode, the JGroups coordinator always plays the role of main lock owner. The coordinator might get overwhelmed as it has to process the additional TxCompletionNotificationCommand on every transaction (direct consequence of being main lock owner). OTOH in distributed mode, the lock owner is spread between the cluster members.
As an optimisation, on REPL mode, we can use multicasting (when on UDP) for message sending.
--
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, 11 months
[JBoss JIRA] (ISPN-2751) NPE after JBossMarshaller stops
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2751?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2751:
------------------------------------
I was actually able to reproduce this while running a test from the IDE.
I think I (we) understood the ISPN-2752 stacktrace incorrectly - {{GroupRequest.requests}} represents the requests sent from the local node, so the {{IllegalStateException}} is thrown when the JChannel shuts down and there are still requests waiting for responses from the other nodes. In that case, we send a CH_UPDATE from a background thread and we don't wait for that thread to end before shutting down the JChannel.
There is a somewhat similar mechanism on the receiving end, as well - when stopping, JChannel calls {{shutdownNow()}} on the TP thread pools, which interrupts the threads. But if the threads don't do any I/O, they don't get a {{InterruptedException}} and they proceed with their work.
In this case the OOB thread was actually was calling {{getorCreateComponent()}} on the GlobalComponentRegistry, which is synchronized. But the main thread was calling {{stop()}} on the GlobalComponentRegistry, which is also synchronized, at the same time. So the OOB thread could not proceed to do anything until the main thread finished stopping the cache manager (which included waiting 3 seconds for the OOB thread pool to shut down).
I think the problem is that {{AbstractComponentRegistry.stop()}} holds the component registry locked for too long. It should not hold the lock while it is invoking {{stop()}} on all the components.
> NPE after JBossMarshaller stops
> -------------------------------
>
> Key: ISPN-2751
> URL: https://issues.jboss.org/browse/ISPN-2751
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling
> Affects Versions: 5.2.0.CR2
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Priority: Minor
> Fix For: 5.2.0.Final
>
> Attachments: serverlogs.zip, serverlogs2.zip
>
>
> JBossMarshaller is used by JGroups even after it's stopped
> which produces NPE on nonexistent externalizerTable:
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
--
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, 11 months
[JBoss JIRA] (ISPN-2664) DistSyncCacheStoreNotSharedNotConcurrentTest.testAtomicPutIfAbsentFromNonOwner fails randomly
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2664?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2664:
-----------------------------------
Fix Version/s: 5.3.0.Final
(was: 5.2.0.Final)
> DistSyncCacheStoreNotSharedNotConcurrentTest.testAtomicPutIfAbsentFromNonOwner fails randomly
> ---------------------------------------------------------------------------------------------
>
> Key: ISPN-2664
> URL: https://issues.jboss.org/browse/ISPN-2664
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 5.3.0.Final
>
> Attachments: testAtomicPutIfAbsentFromNonOwner-0.log, testAtomicPutIfAbsentFromNonOwner-0.log
>
>
> {code}testAtomicPutIfAbsentFromNonOwner(org.infinispan.distribution.DistSyncCacheStoreNotSharedNotConcurrentTest) Time elapsed: 0.004 sec <<< FAILURE!
> java.lang.AssertionError
> at org.infinispan.distribution.DistSyncCacheStoreNotSharedTest.testAtomicPutIfAbsentFromNonOwner(DistSyncCacheStoreNotSharedTest.java:297)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> 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:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 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:680){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, 11 months
[JBoss JIRA] (ISPN-2665) Multiple tests in ReplSyncDistributedExecutorTest failing randomly
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2665?page=com.atlassian.jira.plugin.... ]
Anna Manukyan updated ISPN-2665:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1622
> Multiple tests in ReplSyncDistributedExecutorTest failing randomly
> ------------------------------------------------------------------
>
> Key: ISPN-2665
> URL: https://issues.jboss.org/browse/ISPN-2665
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Execution and Map/Reduce
> Reporter: Galder Zamarreño
> Assignee: Vladimir Blagojevic
> Labels: testsuite_stability
> Fix For: 5.2.0.Final
>
> Attachments: testBasicTargetRemoteDistributedCallableWithHighFutureAndLowTaskTimeout-0.log, testRunnableExecution-1.log
>
>
> {code}testRunnableExecution(org.infinispan.distexec.ReplSyncDistributedExecutorTest) Time elapsed: 0.069 sec <<< FAILURE!
> java.lang.AssertionError
> at org.infinispan.distexec.LocalDistributedExecutorTest.testRunnableExecution(LocalDistributedExecutorTest.java:139)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> 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:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 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:680){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, 11 months