[JBoss JIRA] (ISPN-9844) DistSyncStoreNotSharedTest.clearContent sometimes hangs
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9844?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-9844:
------------------------------------
There's also an interesting (but maybe unrelated) exception in the log:
{noformat}
11:59:57,970 WARN (expiration-thread-Test-NodeA-p12230-t1:[]) [PersistenceManagerImpl] ISPN000026: Caught exception purging data container!
java.lang.UnsupportedOperationException: null
at org.infinispan.persistence.spi.AdvancedCacheExpirationWriter.purge(AdvancedCacheExpirationWriter.java:49) ~[classes/:?]
at org.infinispan.persistence.support.ComposedSegmentedLoadWriteStore.purge(ComposedSegmentedLoadWriteStore.java:166) ~[classes/:?]
at org.infinispan.persistence.manager.PersistenceManagerImpl.lambda$purgeExpired$6(PersistenceManagerImpl.java:462) ~[classes/:?]
at java.util.ArrayList.forEach(ArrayList.java:1257) ~[?:1.8.0_191]
at org.infinispan.persistence.manager.PersistenceManagerImpl.purgeExpired(PersistenceManagerImpl.java:465) [classes/:?]
at org.infinispan.expiration.impl.ClusterExpirationManager.processExpiration(ClusterExpirationManager.java:119) [classes/:?]
{noformat}
> DistSyncStoreNotSharedTest.clearContent sometimes hangs
> -------------------------------------------------------
>
> Key: ISPN-9844
> URL: https://issues.jboss.org/browse/ISPN-9844
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 10.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Ryan Emerson
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta1
>
> Attachments: DistSyncStoreNotSharedTest_20181221.tar.xz, threaddump-org_infinispan_distribution_DistSyncStoreNotSharedTest_clearContent-2018-12-19-7142.log.xz
>
>
> The main test thread is waiting to acquire the write lock of {{storesMutex}}, and a transport thread is waiting for a publisher to give it the keys of stale segments. There's no thread with a {{storesMutex}} read lock acquisition in the stack (although one thread is trying to acquire the read lock), so either we leak a read lock or we hold the read lock for longer than necessary:
> {noformat}
> "testng-DistSyncStoreNotSharedTest" #15 prio=5 os_prio=0 tid=0x00007fd0bce84800 nid=0x1c42 waiting on condition [0x00007fd0888aa000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dc2a5578> (a java.util.concurrent.Semaphore$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.Semaphore.acquireUninterruptibly(Semaphore.java:494)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.stop(PersistenceManagerImpl.java:215)
> "transport-thread-DistSyncStoreNotSharedTest-NodeB-p12241-t1" #46086 daemon prio=5 os_prio=0 tid=0x00007fd09406f800 nid=0x5ee8 waiting on condition [0x00007fd05ce9e000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dc2a4df8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at io.reactivex.internal.operators.flowable.BlockingFlowableIterable$BlockingFlowableIterator.hasNext(BlockingFlowableIterable.java:94)
> at io.reactivex.Flowable.blockingForEach(Flowable.java:5509)
> at org.infinispan.statetransfer.StateConsumerImpl.removeStaleData(StateConsumerImpl.java:993)
> at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:441)
> "persistence-thread-DistSyncStoreNotSharedTest-NodeB-p12255-t1" #46212 daemon prio=5 os_prio=0 tid=0x00007fd09420a000 nid=0x5f66 waiting on condition [0x00007fd044a89000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dc2a4870> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.pollStoreAvailability(PersistenceManagerImpl.java:189)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-9844) DistSyncStoreNotSharedTest.clearContent sometimes hangs
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9844?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9844:
-------------------------------
Attachment: DistSyncStoreNotSharedTest_20181221.tar.xz
threaddump-org_infinispan_distribution_DistSyncStoreNotSharedTest_clearContent-2018-12-19-7142.log.xz
> DistSyncStoreNotSharedTest.clearContent sometimes hangs
> -------------------------------------------------------
>
> Key: ISPN-9844
> URL: https://issues.jboss.org/browse/ISPN-9844
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 10.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Ryan Emerson
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta1
>
> Attachments: DistSyncStoreNotSharedTest_20181221.tar.xz, threaddump-org_infinispan_distribution_DistSyncStoreNotSharedTest_clearContent-2018-12-19-7142.log.xz
>
>
> The main test thread is waiting to acquire the write lock of {{storesMutex}}, and a transport thread is waiting for a publisher to give it the keys of stale segments. There's no thread with a {{storesMutex}} read lock acquisition in the stack (although one thread is trying to acquire the read lock), so either we leak a read lock or we hold the read lock for longer than necessary:
> {noformat}
> "testng-DistSyncStoreNotSharedTest" #15 prio=5 os_prio=0 tid=0x00007fd0bce84800 nid=0x1c42 waiting on condition [0x00007fd0888aa000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dc2a5578> (a java.util.concurrent.Semaphore$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.Semaphore.acquireUninterruptibly(Semaphore.java:494)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.stop(PersistenceManagerImpl.java:215)
> "transport-thread-DistSyncStoreNotSharedTest-NodeB-p12241-t1" #46086 daemon prio=5 os_prio=0 tid=0x00007fd09406f800 nid=0x5ee8 waiting on condition [0x00007fd05ce9e000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dc2a4df8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at io.reactivex.internal.operators.flowable.BlockingFlowableIterable$BlockingFlowableIterator.hasNext(BlockingFlowableIterable.java:94)
> at io.reactivex.Flowable.blockingForEach(Flowable.java:5509)
> at org.infinispan.statetransfer.StateConsumerImpl.removeStaleData(StateConsumerImpl.java:993)
> at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:441)
> "persistence-thread-DistSyncStoreNotSharedTest-NodeB-p12255-t1" #46212 daemon prio=5 os_prio=0 tid=0x00007fd09420a000 nid=0x5f66 waiting on condition [0x00007fd044a89000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dc2a4870> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.pollStoreAvailability(PersistenceManagerImpl.java:189)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-9844) DistSyncStoreNotSharedTest.clearContent sometimes hangs
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9844?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9844:
-------------------------------
Status: Open (was: New)
> DistSyncStoreNotSharedTest.clearContent sometimes hangs
> -------------------------------------------------------
>
> Key: ISPN-9844
> URL: https://issues.jboss.org/browse/ISPN-9844
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 10.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Ryan Emerson
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta1
>
>
> The main test thread is waiting to acquire the write lock of {{storesMutex}}, and a transport thread is waiting for a publisher to give it the keys of stale segments. There's no thread with a {{storesMutex}} read lock acquisition in the stack (although one thread is trying to acquire the read lock), so either we leak a read lock or we hold the read lock for longer than necessary:
> {noformat}
> "testng-DistSyncStoreNotSharedTest" #15 prio=5 os_prio=0 tid=0x00007fd0bce84800 nid=0x1c42 waiting on condition [0x00007fd0888aa000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dc2a5578> (a java.util.concurrent.Semaphore$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.Semaphore.acquireUninterruptibly(Semaphore.java:494)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.stop(PersistenceManagerImpl.java:215)
> "transport-thread-DistSyncStoreNotSharedTest-NodeB-p12241-t1" #46086 daemon prio=5 os_prio=0 tid=0x00007fd09406f800 nid=0x5ee8 waiting on condition [0x00007fd05ce9e000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dc2a4df8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at io.reactivex.internal.operators.flowable.BlockingFlowableIterable$BlockingFlowableIterator.hasNext(BlockingFlowableIterable.java:94)
> at io.reactivex.Flowable.blockingForEach(Flowable.java:5509)
> at org.infinispan.statetransfer.StateConsumerImpl.removeStaleData(StateConsumerImpl.java:993)
> at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:441)
> "persistence-thread-DistSyncStoreNotSharedTest-NodeB-p12255-t1" #46212 daemon prio=5 os_prio=0 tid=0x00007fd09420a000 nid=0x5f66 waiting on condition [0x00007fd044a89000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dc2a4870> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.pollStoreAvailability(PersistenceManagerImpl.java:189)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-9844) DistSyncStoreNotSharedTest.clearContent sometimes hangs
by Dan Berindei (Jira)
Dan Berindei created ISPN-9844:
----------------------------------
Summary: DistSyncStoreNotSharedTest.clearContent sometimes hangs
Key: ISPN-9844
URL: https://issues.jboss.org/browse/ISPN-9844
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 10.0.0.Alpha2
Reporter: Dan Berindei
Assignee: Ryan Emerson
Fix For: 10.0.0.Beta1
The main test thread is waiting to acquire the write lock of {{storesMutex}}, and a transport thread is waiting for a publisher to give it the keys of stale segments. There's no thread with a {{storesMutex}} read lock acquisition in the stack (although one thread is trying to acquire the read lock), so either we leak a read lock or we hold the read lock for longer than necessary:
{noformat}
"testng-DistSyncStoreNotSharedTest" #15 prio=5 os_prio=0 tid=0x00007fd0bce84800 nid=0x1c42 waiting on condition [0x00007fd0888aa000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000dc2a5578> (a java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at java.util.concurrent.Semaphore.acquireUninterruptibly(Semaphore.java:494)
at org.infinispan.persistence.manager.PersistenceManagerImpl.stop(PersistenceManagerImpl.java:215)
"transport-thread-DistSyncStoreNotSharedTest-NodeB-p12241-t1" #46086 daemon prio=5 os_prio=0 tid=0x00007fd09406f800 nid=0x5ee8 waiting on condition [0x00007fd05ce9e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000dc2a4df8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at io.reactivex.internal.operators.flowable.BlockingFlowableIterable$BlockingFlowableIterator.hasNext(BlockingFlowableIterable.java:94)
at io.reactivex.Flowable.blockingForEach(Flowable.java:5509)
at org.infinispan.statetransfer.StateConsumerImpl.removeStaleData(StateConsumerImpl.java:993)
at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:441)
"persistence-thread-DistSyncStoreNotSharedTest-NodeB-p12255-t1" #46212 daemon prio=5 os_prio=0 tid=0x00007fd09420a000 nid=0x5f66 waiting on condition [0x00007fd044a89000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000dc2a4870> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at org.infinispan.persistence.manager.PersistenceManagerImpl.pollStoreAvailability(PersistenceManagerImpl.java:189)
{noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-9824) Unable to build Infinispan with JDK 11
by Rostislav Svoboda (Jira)
[ https://issues.jboss.org/browse/ISPN-9824?page=com.atlassian.jira.plugin.... ]
Rostislav Svoboda commented on ISPN-9824:
-----------------------------------------
When playing with javadoc/doclets module I get 36 errors.
When I did following changes I got 2 errors saying the same - package com.sun.tools.doclets.formats.html does not exist.
This package was present in Java 9 but was not exported, in Java 10 or 11 it vanished completely.
This is probably due to http://openjdk.java.net/jeps/221
Having custom doclets seems like a big maintenance burden.
Applied changes:
{code:diff}
@@ -4957,10 +4957,13 @@
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
- <compilerArgument combine.children="append">-XDignore.symbol.file</compilerArgument>
+ <compilerArgs combine.children="append">
+ <arg>-XDignore.symbol.file</arg>
+ <arg>--add-modules=jdk.javadoc</arg>
+ </compilerArgs>
<!-- Forking is necessary to allow for the compiler args to be picked up. -->
<fork combine.children="append">true</fork>
- <release>8</release>
+ <release>9</release>
<!-- Include a skeleton implementation of some classes removed in JDK10+ -->
<additionalClasspathElements>
<additionalClasspathElement>${project.build.directory}/jdk-misc.jar</additionalClasspathElement>
{code}
> Unable to build Infinispan with JDK 11
> --------------------------------------
>
> Key: ISPN-9824
> URL: https://issues.jboss.org/browse/ISPN-9824
> Project: Infinispan
> Issue Type: Bug
> Components: Build
> Affects Versions: 9.4.3.Final
> Reporter: Vladimir Dosoudil
> Priority: Major
>
> It's not able to build Infinispan with JDK 11.
> Module infinispan-commons contains JDK specific classes which requires to be built in JDK 9+ (JDK 11 is LTS) but it's not able to build the whole Infinispan project with distribution profile related to fails on missing classes for infinispan-doclets module (referencing com.sun.javadoc*) using tools.jar which are not the part of JDK 9+ anymore. The failure is also on generating javadoc for infinispan-commons which uses sun.reflect.Reflection.getCallerClass which is discontinuing in JDK 11.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-9842) Hotrod ConfigurationBuilder#withProperties loads classes when not needed.
by William Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-9842?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-9842:
--------------------------------
Summary: Hotrod ConfigurationBuilder#withProperties loads classes when not needed. (was: Hotrod ConfigurationBuilder#withProperties loads ConsistentHash classes when not needed.)
> Hotrod ConfigurationBuilder#withProperties loads classes when not needed.
> -------------------------------------------------------------------------
>
> Key: ISPN-9842
> URL: https://issues.jboss.org/browse/ISPN-9842
> Project: Infinispan
> Issue Type: Bug
> Components: Hot Rod
> Reporter: William Burns
> Assignee: William Burns
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> The ConfigurationBuilder#withProperties loads and replaces all the consistent hash class instances with themselves even if no override is provided. We shouldn't need to do this extra class loading work.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months