[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
by Manik Surtani (JIRA)
[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ]
Manik Surtani updated ISPN-2956:
--------------------------------
Labels: hotrod-java-client remote-clients (was: )
> putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
> -------------------------------------------------------------------
>
> Key: ISPN-2956
> URL: https://issues.jboss.org/browse/ISPN-2956
> Project: Infinispan
> Issue Type: Bug
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: hotrod-java-client, remote-clients
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> Hot Rod's putIfAbsent might have issues on some edge cases:
> {quote}I want to know whether the putting entry already exists in the remote
> cache cluster, or not.
> I thought that RemoteCache.putIfAbsent() would be useful for that
> purpose, i.e.,
> {code}
> if (remoteCache.putIfAbsent(k,v) == null) {
> // new entry.
> } else {
> // k already exists.
> }
> {code}
> But no.
> The putIfAbsent() for new entry may return non-null value, if one of the
> server crushed while putting.
> The behavior is like the following:
> 1. Client do putIfAbsent(k,v).
> 2. The server receives the request and sends replication requests to
> other servers. If the server crushed before completing replication, some
> servers own that (k,v), but others not.
> 3. Client receives the error. The putIfAbsent() internally retries the
> same request to the next server in the cluster server list.
> 4. If the next server owns the (k,v), the putIfAbsent() returns the
> replicated (k,v) at the step 2, without any error.
> So, putIfAbsent() is not reliable for knowing whether the putting entry
> is *exactly* new or not.
> Does anyone have any idea/workaround for this purpose?{quote}
> A workaround is to do this:
> {quote}We got a simple solution, which can be applied to our customer's application.
> If each value part of putting (k,v) is unique or contains unique value,
> the client can do *double check* wether the entry is new.
> {code}
> val = System.nanoTime(); // or uuid is also useful.
> if ((ret = cache.putIfAbsent(key, val)) == null
> || ret.equals(val)) {
> // new entry, if the return value is just the same.
> } else {
> // key already exists.
> }
> {code}
> We are proposing this workaround which almost works fine.{quote}
> However, this is a bit of a cludge.
> Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it.
--
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
12 years, 6 months
[JBoss JIRA] (ISPN-2956) Hot Rod putIfAbsent doesn't reliably fulfil contract
by Manik Surtani (JIRA)
[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ]
Manik Surtani updated ISPN-2956:
--------------------------------
Summary: Hot Rod putIfAbsent doesn't reliably fulfil contract (was: Hot Rod putIfAbsent to take version to handle edge cases)
> Hot Rod putIfAbsent doesn't reliably fulfil contract
> ----------------------------------------------------
>
> Key: ISPN-2956
> URL: https://issues.jboss.org/browse/ISPN-2956
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> Hot Rod's putIfAbsent might have issues on some edge cases:
> {quote}I want to know whether the putting entry already exists in the remote
> cache cluster, or not.
> I thought that RemoteCache.putIfAbsent() would be useful for that
> purpose, i.e.,
> {code}
> if (remoteCache.putIfAbsent(k,v) == null) {
> // new entry.
> } else {
> // k already exists.
> }
> {code}
> But no.
> The putIfAbsent() for new entry may return non-null value, if one of the
> server crushed while putting.
> The behavior is like the following:
> 1. Client do putIfAbsent(k,v).
> 2. The server receives the request and sends replication requests to
> other servers. If the server crushed before completing replication, some
> servers own that (k,v), but others not.
> 3. Client receives the error. The putIfAbsent() internally retries the
> same request to the next server in the cluster server list.
> 4. If the next server owns the (k,v), the putIfAbsent() returns the
> replicated (k,v) at the step 2, without any error.
> So, putIfAbsent() is not reliable for knowing whether the putting entry
> is *exactly* new or not.
> Does anyone have any idea/workaround for this purpose?{quote}
> A workaround is to do this:
> {quote}We got a simple solution, which can be applied to our customer's application.
> If each value part of putting (k,v) is unique or contains unique value,
> the client can do *double check* wether the entry is new.
> {code}
> val = System.nanoTime(); // or uuid is also useful.
> if ((ret = cache.putIfAbsent(key, val)) == null
> || ret.equals(val)) {
> // new entry, if the return value is just the same.
> } else {
> // key already exists.
> }
> {code}
> We are proposing this workaround which almost works fine.{quote}
> However, this is a bit of a cludge.
> Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it.
--
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
12 years, 6 months
[JBoss JIRA] (ISPN-2906) SyncCacheListenerTest.testSyncTxRepl failing randomly
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2906?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2906:
-------------------------------------
I've seen it fail again on master with age==null but unfortunately I only have debug log, no trace :(.
> SyncCacheListenerTest.testSyncTxRepl failing randomly
> -----------------------------------------------------
>
> Key: ISPN-2906
> URL: https://issues.jboss.org/browse/ISPN-2906
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners, Transactions
> Reporter: Galder Zamarreño
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Fix For: 5.3.0.Alpha1
>
> Attachments: testSyncTxRepl-0.log
>
>
> {code}testSyncTxRepl(org.infinispan.replication.SyncCacheListenerTest) Time elapsed: 0.04 sec <<< FAILURE!
> java.lang.AssertionError: "age" obtained from cache2 must be non-null
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
> at org.testng.AssertJUnit.assertNotNull(AssertJUnit.java:267)
> at org.infinispan.replication.SyncCacheListenerTest.testSyncTxRepl(SyncCacheListenerTest.java:99)
> 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:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> 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){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
12 years, 6 months
[JBoss JIRA] (ISPN-2962) Fix thread leaks in the core test suite
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2962?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2962:
-------------------------------------
I added my PR which fixes all the stray threads I could find. Please add your fixes to it.
> Fix thread leaks in the core test suite
> ---------------------------------------
>
> Key: ISPN-2962
> URL: https://issues.jboss.org/browse/ISPN-2962
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite
> Affects Versions: 5.2.5.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.3.0.Final
>
>
> The core test suite leaks several threads, which then keep their context classloaders alive and cause PermGen leaks.
> For example, I found these tests still alive at the end of a test run:
> {noformat}
> "Scheduled-eviction-thread-2486" daemon prio=10 tid=0x00007f2d6009e000 nid=0xecd waiting on condition [0x00007f2d48278000]
> "Scheduled-eviction-thread-2485" daemon prio=10 tid=0x00007f2d600b7800 nid=0xeb6 waiting on condition [0x00007f2d3f549000]
> "Scheduled-eviction-thread-2484" daemon prio=10 tid=0x00007f2d6005d000 nid=0xe9d waiting on condition [0x00007f2d22aca000]
> "AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001cbf000 nid=0xb33 waiting on condition [0x00007f2d2b094000]
> "AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001ca4000 nid=0xb1e waiting on condition [0x00007f2d3bbab000]
> "AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001c9f000 nid=0xaee waiting on condition [0x00007f2db113b000]
> "AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001cb7800 nid=0x8bf waiting on condition [0x00007f2d488d1000]
> "transport-thread-0,ReplSyncDistributedExecutorTest-NodeCD" daemon prio=10 tid=0x00007f2d64784000 nid=0x5308 waiting on condition [0x00007f2d7261d000]
> "transport-thread-0,DistributedExecutorWithCacheLoaderTest-NodeBN" daemon prio=10 tid=0x00007f2d64403800 nid=0x4b38 waiting on condition [0x00007f2d42a82000]
> "transport-thread-0,DistributedExecutorWithCacheLoaderTest-NodeBH" daemon prio=10 tid=0x00007f2d643f3800 nid=0x4840 waiting on condition [0x00007f2d35bf7000]
> "asyncTransportThread-0,ReplSyncDistributedExecutorWithTopologyAwareNodesTest-NodeAV" daemon prio=10 tid=0x00007f2d646a8800 nid=0x41ca waiting on condition [0x00007f2d3b552000]
> "transport-thread-0,DistributedExecutorWithCacheLoaderTest-NodeAP" daemon prio=10 tid=0x00007f2d644d6000 nid=0x3edc waiting on condition [0x00007f2d7290b000]
> "transport-thread-0,DistributedExecutorNonConcurrentTest-NodeAJ" daemon prio=10 tid=0x00007f2d645a0000 nid=0x3be6 waiting on condition [0x00007f2d39ce8000]
> "transport-thread-0,DistributedExecutorTest-NodeH" daemon prio=10 tid=0x00007f2d6406b000 nid=0x2af6 waiting on condition [0x00007f2d4261d000]
> "transport-thread-0,DistributedExecutorTest-NodeD" daemon prio=10 tid=0x00007f2d6410f000 nid=0x283f waiting on condition [0x00007f2d43e87000]
> "transport-thread-0,InDoubtXidReturnedOnceTest-NodeC" daemon prio=10 tid=0x00007f2d64621000 nid=0x188b waiting on condition [0x00007f2d4a988000]
> "Scheduled-eviction-thread-409" daemon prio=10 tid=0x00007f2d600b5000 nid=0x6ac3 waiting on condition [0x00007f2d2cbec000]
> "Scheduled-eviction-thread-403" daemon prio=10 tid=0x00007f2d600ad000 nid=0x6a35 waiting on condition [0x00007f2d2924e000]
> "Scheduled-eviction-thread-396" daemon prio=10 tid=0x00007f2d60089000 nid=0x698c waiting on condition [0x00007f2d30a6c000]
> "Scheduled-eviction-thread-390" daemon prio=10 tid=0x00007f2d60052000 nid=0x6903 waiting on condition [0x00007f2d3d703000]
> "pool-292-thread-2" prio=10 tid=0x00007f2d6c0bb000 nid=0x5cb3 waiting on condition [0x00007f2db0218000]
> "pool-292-thread-1" prio=10 tid=0x00007f2d6c073000 nid=0x5cb2 waiting on condition [0x00007f2d3aef9000]
> {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
12 years, 6 months
[JBoss JIRA] (ISPN-2962) Fix thread leaks in the core test suite
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2962?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2962:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1736
> Fix thread leaks in the core test suite
> ---------------------------------------
>
> Key: ISPN-2962
> URL: https://issues.jboss.org/browse/ISPN-2962
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite
> Affects Versions: 5.2.5.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.3.0.Final
>
>
> The core test suite leaks several threads, which then keep their context classloaders alive and cause PermGen leaks.
> For example, I found these tests still alive at the end of a test run:
> {noformat}
> "Scheduled-eviction-thread-2486" daemon prio=10 tid=0x00007f2d6009e000 nid=0xecd waiting on condition [0x00007f2d48278000]
> "Scheduled-eviction-thread-2485" daemon prio=10 tid=0x00007f2d600b7800 nid=0xeb6 waiting on condition [0x00007f2d3f549000]
> "Scheduled-eviction-thread-2484" daemon prio=10 tid=0x00007f2d6005d000 nid=0xe9d waiting on condition [0x00007f2d22aca000]
> "AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001cbf000 nid=0xb33 waiting on condition [0x00007f2d2b094000]
> "AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001ca4000 nid=0xb1e waiting on condition [0x00007f2d3bbab000]
> "AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001c9f000 nid=0xaee waiting on condition [0x00007f2db113b000]
> "AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001cb7800 nid=0x8bf waiting on condition [0x00007f2d488d1000]
> "transport-thread-0,ReplSyncDistributedExecutorTest-NodeCD" daemon prio=10 tid=0x00007f2d64784000 nid=0x5308 waiting on condition [0x00007f2d7261d000]
> "transport-thread-0,DistributedExecutorWithCacheLoaderTest-NodeBN" daemon prio=10 tid=0x00007f2d64403800 nid=0x4b38 waiting on condition [0x00007f2d42a82000]
> "transport-thread-0,DistributedExecutorWithCacheLoaderTest-NodeBH" daemon prio=10 tid=0x00007f2d643f3800 nid=0x4840 waiting on condition [0x00007f2d35bf7000]
> "asyncTransportThread-0,ReplSyncDistributedExecutorWithTopologyAwareNodesTest-NodeAV" daemon prio=10 tid=0x00007f2d646a8800 nid=0x41ca waiting on condition [0x00007f2d3b552000]
> "transport-thread-0,DistributedExecutorWithCacheLoaderTest-NodeAP" daemon prio=10 tid=0x00007f2d644d6000 nid=0x3edc waiting on condition [0x00007f2d7290b000]
> "transport-thread-0,DistributedExecutorNonConcurrentTest-NodeAJ" daemon prio=10 tid=0x00007f2d645a0000 nid=0x3be6 waiting on condition [0x00007f2d39ce8000]
> "transport-thread-0,DistributedExecutorTest-NodeH" daemon prio=10 tid=0x00007f2d6406b000 nid=0x2af6 waiting on condition [0x00007f2d4261d000]
> "transport-thread-0,DistributedExecutorTest-NodeD" daemon prio=10 tid=0x00007f2d6410f000 nid=0x283f waiting on condition [0x00007f2d43e87000]
> "transport-thread-0,InDoubtXidReturnedOnceTest-NodeC" daemon prio=10 tid=0x00007f2d64621000 nid=0x188b waiting on condition [0x00007f2d4a988000]
> "Scheduled-eviction-thread-409" daemon prio=10 tid=0x00007f2d600b5000 nid=0x6ac3 waiting on condition [0x00007f2d2cbec000]
> "Scheduled-eviction-thread-403" daemon prio=10 tid=0x00007f2d600ad000 nid=0x6a35 waiting on condition [0x00007f2d2924e000]
> "Scheduled-eviction-thread-396" daemon prio=10 tid=0x00007f2d60089000 nid=0x698c waiting on condition [0x00007f2d30a6c000]
> "Scheduled-eviction-thread-390" daemon prio=10 tid=0x00007f2d60052000 nid=0x6903 waiting on condition [0x00007f2d3d703000]
> "pool-292-thread-2" prio=10 tid=0x00007f2d6c0bb000 nid=0x5cb3 waiting on condition [0x00007f2db0218000]
> "pool-292-thread-1" prio=10 tid=0x00007f2d6c073000 nid=0x5cb2 waiting on condition [0x00007f2d3aef9000]
> {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
12 years, 6 months
[JBoss JIRA] (ISPN-2962) Fix thread leaks in the core test suite
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2962?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2962:
-------------------------------------
Hi Dan, I fixed all these problems in core last Friday. Did not look in the other modules.
> Fix thread leaks in the core test suite
> ---------------------------------------
>
> Key: ISPN-2962
> URL: https://issues.jboss.org/browse/ISPN-2962
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite
> Affects Versions: 5.2.5.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.3.0.Final
>
>
> The core test suite leaks several threads, which then keep their context classloaders alive and cause PermGen leaks.
> For example, I found these tests still alive at the end of a test run:
> {noformat}
> "Scheduled-eviction-thread-2486" daemon prio=10 tid=0x00007f2d6009e000 nid=0xecd waiting on condition [0x00007f2d48278000]
> "Scheduled-eviction-thread-2485" daemon prio=10 tid=0x00007f2d600b7800 nid=0xeb6 waiting on condition [0x00007f2d3f549000]
> "Scheduled-eviction-thread-2484" daemon prio=10 tid=0x00007f2d6005d000 nid=0xe9d waiting on condition [0x00007f2d22aca000]
> "AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001cbf000 nid=0xb33 waiting on condition [0x00007f2d2b094000]
> "AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001ca4000 nid=0xb1e waiting on condition [0x00007f2d3bbab000]
> "AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001c9f000 nid=0xaee waiting on condition [0x00007f2db113b000]
> "AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001cb7800 nid=0x8bf waiting on condition [0x00007f2d488d1000]
> "transport-thread-0,ReplSyncDistributedExecutorTest-NodeCD" daemon prio=10 tid=0x00007f2d64784000 nid=0x5308 waiting on condition [0x00007f2d7261d000]
> "transport-thread-0,DistributedExecutorWithCacheLoaderTest-NodeBN" daemon prio=10 tid=0x00007f2d64403800 nid=0x4b38 waiting on condition [0x00007f2d42a82000]
> "transport-thread-0,DistributedExecutorWithCacheLoaderTest-NodeBH" daemon prio=10 tid=0x00007f2d643f3800 nid=0x4840 waiting on condition [0x00007f2d35bf7000]
> "asyncTransportThread-0,ReplSyncDistributedExecutorWithTopologyAwareNodesTest-NodeAV" daemon prio=10 tid=0x00007f2d646a8800 nid=0x41ca waiting on condition [0x00007f2d3b552000]
> "transport-thread-0,DistributedExecutorWithCacheLoaderTest-NodeAP" daemon prio=10 tid=0x00007f2d644d6000 nid=0x3edc waiting on condition [0x00007f2d7290b000]
> "transport-thread-0,DistributedExecutorNonConcurrentTest-NodeAJ" daemon prio=10 tid=0x00007f2d645a0000 nid=0x3be6 waiting on condition [0x00007f2d39ce8000]
> "transport-thread-0,DistributedExecutorTest-NodeH" daemon prio=10 tid=0x00007f2d6406b000 nid=0x2af6 waiting on condition [0x00007f2d4261d000]
> "transport-thread-0,DistributedExecutorTest-NodeD" daemon prio=10 tid=0x00007f2d6410f000 nid=0x283f waiting on condition [0x00007f2d43e87000]
> "transport-thread-0,InDoubtXidReturnedOnceTest-NodeC" daemon prio=10 tid=0x00007f2d64621000 nid=0x188b waiting on condition [0x00007f2d4a988000]
> "Scheduled-eviction-thread-409" daemon prio=10 tid=0x00007f2d600b5000 nid=0x6ac3 waiting on condition [0x00007f2d2cbec000]
> "Scheduled-eviction-thread-403" daemon prio=10 tid=0x00007f2d600ad000 nid=0x6a35 waiting on condition [0x00007f2d2924e000]
> "Scheduled-eviction-thread-396" daemon prio=10 tid=0x00007f2d60089000 nid=0x698c waiting on condition [0x00007f2d30a6c000]
> "Scheduled-eviction-thread-390" daemon prio=10 tid=0x00007f2d60052000 nid=0x6903 waiting on condition [0x00007f2d3d703000]
> "pool-292-thread-2" prio=10 tid=0x00007f2d6c0bb000 nid=0x5cb3 waiting on condition [0x00007f2db0218000]
> "pool-292-thread-1" prio=10 tid=0x00007f2d6c073000 nid=0x5cb2 waiting on condition [0x00007f2d3aef9000]
> {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
12 years, 6 months
[JBoss JIRA] (ISPN-2962) Fix thread leaks in the core test suite
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2962:
----------------------------------
Summary: Fix thread leaks in the core test suite
Key: ISPN-2962
URL: https://issues.jboss.org/browse/ISPN-2962
Project: Infinispan
Issue Type: Task
Components: Test Suite
Affects Versions: 5.2.5.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.3.0.Final
The core test suite leaks several threads, which then keep their context classloaders alive and cause PermGen leaks.
For example, I found these tests still alive at the end of a test run:
{noformat}
"Scheduled-eviction-thread-2486" daemon prio=10 tid=0x00007f2d6009e000 nid=0xecd waiting on condition [0x00007f2d48278000]
"Scheduled-eviction-thread-2485" daemon prio=10 tid=0x00007f2d600b7800 nid=0xeb6 waiting on condition [0x00007f2d3f549000]
"Scheduled-eviction-thread-2484" daemon prio=10 tid=0x00007f2d6005d000 nid=0xe9d waiting on condition [0x00007f2d22aca000]
"AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001cbf000 nid=0xb33 waiting on condition [0x00007f2d2b094000]
"AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001ca4000 nid=0xb1e waiting on condition [0x00007f2d3bbab000]
"AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001c9f000 nid=0xaee waiting on condition [0x00007f2db113b000]
"AsyncStoreCoordinator-null" daemon prio=10 tid=0x0000000001cb7800 nid=0x8bf waiting on condition [0x00007f2d488d1000]
"transport-thread-0,ReplSyncDistributedExecutorTest-NodeCD" daemon prio=10 tid=0x00007f2d64784000 nid=0x5308 waiting on condition [0x00007f2d7261d000]
"transport-thread-0,DistributedExecutorWithCacheLoaderTest-NodeBN" daemon prio=10 tid=0x00007f2d64403800 nid=0x4b38 waiting on condition [0x00007f2d42a82000]
"transport-thread-0,DistributedExecutorWithCacheLoaderTest-NodeBH" daemon prio=10 tid=0x00007f2d643f3800 nid=0x4840 waiting on condition [0x00007f2d35bf7000]
"asyncTransportThread-0,ReplSyncDistributedExecutorWithTopologyAwareNodesTest-NodeAV" daemon prio=10 tid=0x00007f2d646a8800 nid=0x41ca waiting on condition [0x00007f2d3b552000]
"transport-thread-0,DistributedExecutorWithCacheLoaderTest-NodeAP" daemon prio=10 tid=0x00007f2d644d6000 nid=0x3edc waiting on condition [0x00007f2d7290b000]
"transport-thread-0,DistributedExecutorNonConcurrentTest-NodeAJ" daemon prio=10 tid=0x00007f2d645a0000 nid=0x3be6 waiting on condition [0x00007f2d39ce8000]
"transport-thread-0,DistributedExecutorTest-NodeH" daemon prio=10 tid=0x00007f2d6406b000 nid=0x2af6 waiting on condition [0x00007f2d4261d000]
"transport-thread-0,DistributedExecutorTest-NodeD" daemon prio=10 tid=0x00007f2d6410f000 nid=0x283f waiting on condition [0x00007f2d43e87000]
"transport-thread-0,InDoubtXidReturnedOnceTest-NodeC" daemon prio=10 tid=0x00007f2d64621000 nid=0x188b waiting on condition [0x00007f2d4a988000]
"Scheduled-eviction-thread-409" daemon prio=10 tid=0x00007f2d600b5000 nid=0x6ac3 waiting on condition [0x00007f2d2cbec000]
"Scheduled-eviction-thread-403" daemon prio=10 tid=0x00007f2d600ad000 nid=0x6a35 waiting on condition [0x00007f2d2924e000]
"Scheduled-eviction-thread-396" daemon prio=10 tid=0x00007f2d60089000 nid=0x698c waiting on condition [0x00007f2d30a6c000]
"Scheduled-eviction-thread-390" daemon prio=10 tid=0x00007f2d60052000 nid=0x6903 waiting on condition [0x00007f2d3d703000]
"pool-292-thread-2" prio=10 tid=0x00007f2d6c0bb000 nid=0x5cb3 waiting on condition [0x00007f2db0218000]
"pool-292-thread-1" prio=10 tid=0x00007f2d6c073000 nid=0x5cb2 waiting on condition [0x00007f2d3aef9000]
{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
12 years, 6 months
[JBoss JIRA] (ISPN-2956) Hot Rod putIfAbsent to take version to handle edge cases
by Manik Surtani (JIRA)
[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ]
Manik Surtani commented on ISPN-2956:
-------------------------------------
... and why does this rely on versions? The fix proposed doesn't ... it just checks the return value for equality against the provided value.
> Hot Rod putIfAbsent to take version to handle edge cases
> --------------------------------------------------------
>
> Key: ISPN-2956
> URL: https://issues.jboss.org/browse/ISPN-2956
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> Hot Rod's putIfAbsent might have issues on some edge cases:
> {quote}I want to know whether the putting entry already exists in the remote
> cache cluster, or not.
> I thought that RemoteCache.putIfAbsent() would be useful for that
> purpose, i.e.,
> {code}
> if (remoteCache.putIfAbsent(k,v) == null) {
> // new entry.
> } else {
> // k already exists.
> }
> {code}
> But no.
> The putIfAbsent() for new entry may return non-null value, if one of the
> server crushed while putting.
> The behavior is like the following:
> 1. Client do putIfAbsent(k,v).
> 2. The server receives the request and sends replication requests to
> other servers. If the server crushed before completing replication, some
> servers own that (k,v), but others not.
> 3. Client receives the error. The putIfAbsent() internally retries the
> same request to the next server in the cluster server list.
> 4. If the next server owns the (k,v), the putIfAbsent() returns the
> replicated (k,v) at the step 2, without any error.
> So, putIfAbsent() is not reliable for knowing whether the putting entry
> is *exactly* new or not.
> Does anyone have any idea/workaround for this purpose?{quote}
> A workaround is to do this:
> {quote}We got a simple solution, which can be applied to our customer's application.
> If each value part of putting (k,v) is unique or contains unique value,
> the client can do *double check* wether the entry is new.
> {code}
> val = System.nanoTime(); // or uuid is also useful.
> if ((ret = cache.putIfAbsent(key, val)) == null
> || ret.equals(val)) {
> // new entry, if the return value is just the same.
> } else {
> // key already exists.
> }
> {code}
> We are proposing this workaround which almost works fine.{quote}
> However, this is a bit of a cludge.
> Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it.
--
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
12 years, 6 months
[JBoss JIRA] (ISPN-2956) Hot Rod putIfAbsent to take version to handle edge cases
by Manik Surtani (JIRA)
[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ]
Manik Surtani commented on ISPN-2956:
-------------------------------------
This can easily be wrapped up in the client's putIfAbsent() impl, right?
> Hot Rod putIfAbsent to take version to handle edge cases
> --------------------------------------------------------
>
> Key: ISPN-2956
> URL: https://issues.jboss.org/browse/ISPN-2956
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 6.0.0.Final
>
>
> Hot Rod's putIfAbsent might have issues on some edge cases:
> {quote}I want to know whether the putting entry already exists in the remote
> cache cluster, or not.
> I thought that RemoteCache.putIfAbsent() would be useful for that
> purpose, i.e.,
> {code}
> if (remoteCache.putIfAbsent(k,v) == null) {
> // new entry.
> } else {
> // k already exists.
> }
> {code}
> But no.
> The putIfAbsent() for new entry may return non-null value, if one of the
> server crushed while putting.
> The behavior is like the following:
> 1. Client do putIfAbsent(k,v).
> 2. The server receives the request and sends replication requests to
> other servers. If the server crushed before completing replication, some
> servers own that (k,v), but others not.
> 3. Client receives the error. The putIfAbsent() internally retries the
> same request to the next server in the cluster server list.
> 4. If the next server owns the (k,v), the putIfAbsent() returns the
> replicated (k,v) at the step 2, without any error.
> So, putIfAbsent() is not reliable for knowing whether the putting entry
> is *exactly* new or not.
> Does anyone have any idea/workaround for this purpose?{quote}
> A workaround is to do this:
> {quote}We got a simple solution, which can be applied to our customer's application.
> If each value part of putting (k,v) is unique or contains unique value,
> the client can do *double check* wether the entry is new.
> {code}
> val = System.nanoTime(); // or uuid is also useful.
> if ((ret = cache.putIfAbsent(key, val)) == null
> || ret.equals(val)) {
> // new entry, if the return value is just the same.
> } else {
> // key already exists.
> }
> {code}
> We are proposing this workaround which almost works fine.{quote}
> However, this is a bit of a cludge.
> Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it.
--
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
12 years, 6 months