[JBoss JIRA] (ISPN-9714) Update CacheNotifier to return CompletionStage
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9714?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9714:
----------------------------------
Fix Version/s: 10.0.0.Beta1
(was: 10.0.0.Alpha3)
> Update CacheNotifier to return CompletionStage
> ----------------------------------------------
>
> Key: ISPN-9714
> URL: https://issues.jboss.org/browse/ISPN-9714
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core, Listeners
> Reporter: William Burns
> Assignee: William Burns
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> We need to update CacheNotifier to return CompletionStage for all its appropriate methods. We also need to update all the internals to use these appropriately.
> Not all notification usages may provide support non blocking, but our listener internals should support non blocking listeners for all.
> The simplest way internally is to treat all current listeners as "alien" and invoke them in the notification thread pool. If it is sync we would wait for this task to complete. We would also now allow a listener to return a CompletionStage. If this is returned we will use this operate in a non blocking way.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (ISPN-9778) XidImpl implementations can optimize some byte[] allocations
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9778?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9778:
----------------------------------
Fix Version/s: 10.0.0.Beta1
(was: 10.0.0.Alpha3)
> XidImpl implementations can optimize some byte[] allocations
> ------------------------------------------------------------
>
> Key: ISPN-9778
> URL: https://issues.jboss.org/browse/ISPN-9778
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Reporter: William Burns
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> The EmbeddedXid and XidImpl classes show up on profiler for allocating byte[] in a local environment.
> 1. We should be able to remove the branch byte[] completely as well as its accompanying AtomicInteger and just return an empty byte[] that is cached (ie. Util.EMPTY_BYTE_ARRAY).
> 2. We can use the byte[] that is provided from the create method directly in XidImpl, which would reduce our allocation to just the 1 byte\[24\] for embedded or byte\[32\] for remote.
> -3. We can return the byte[] directly for getGlobalTransactionId without copying.-
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (ISPN-9759) Hot Rod server non-hash aware topology updates can include non-members
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9759?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9759:
----------------------------------
Fix Version/s: 10.0.0.Beta1
(was: 10.0.0.Alpha3)
> Hot Rod server non-hash aware topology updates can include non-members
> ----------------------------------------------------------------------
>
> Key: ISPN-9759
> URL: https://issues.jboss.org/browse/ISPN-9759
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.4.2.Final
> Reporter: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta1
>
> Attachments: HotRod12ReplicationTest.log.gz
>
>
> When sending a non-hash aware topology update, the server includes all the servers that are present in the topology cache. This includes both servers that don't have the cache running yet (if the cache was started dynamically) and servers that are shutting down or already shutdown (because a node doesn't remove itself from the address cache before shutting down).
> When a node shut down, the remaining nodes eventually see the view change and remove the stopped server from the address cache, but likely after sending a topology update with the new topology id to the clients. In cases where a rebalance is not necessary (e.g. replicated caches, or a single node is alive), a corrected topology update is never sent to the client.
> This is causing random failures in {{HotRod10ReplicationTest.testReplicatedPutWithTopologyChanges}},{{HotRodReplicationTest.testReplicatedPutWithTopologyChanges}} and {{HotRod12ReplicationTest.testReplicatedPutWithTopologyChanges}}
> I saw it on a pull request build first, but I see it (and its subclasses) has been randomly failing in master as well. I am able to reliably reproduce the failure on my machine if I add a small delay in {{CrashedMemberDetectorListener.detectCrashedMember()}}.
> {noformat}
> 16:24:18,288 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.server.hotrod.HotRod12ReplicationTest.testReplicatedPutWithTopologyChanges
> java.lang.AssertionError: expected:<3> but was:<2>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.9.9.jar:?]
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.9.9.jar:?]
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.9.9.jar:?]
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) ~[testng-6.9.9.jar:?]
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) ~[testng-6.9.9.jar:?]
> at org.infinispan.server.hotrod.HotRodReplicationTest.testReplicatedPutWithTopologyChanges(HotRodReplicationTest.java:145) ~[test-classes/:?]
> {noformat}
> https://ci.infinispan.org/job/Infinispan/job/master/878/
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (ISPN-9801) ClusterTopologyManagerImpl hangs when restarting a node with FORK
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9801?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9801:
----------------------------------
Fix Version/s: 10.0.0.Beta1
(was: 10.0.0.Alpha3)
> ClusterTopologyManagerImpl hangs when restarting a node with FORK
> -----------------------------------------------------------------
>
> Key: ISPN-9801
> URL: https://issues.jboss.org/browse/ISPN-9801
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.Alpha1, 9.4.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta1, 9.4.6.Final
>
>
> When a server is restarted with `kill -9` or similar, both the old node and the new one can be in the JGroups view for a while. Normally this shouldn't be a problem, but sometimes the new node doesn't receive the {{HeartBeatCommand}} and the coordinator cannot process any new view updates.
> {noformat}
> 14:29:19,981 INFO (jgroups-12,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [ClusterTopologyManagerImpl] Updating cluster members for all the caches. New list is [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [JGroupsTransport] Test-NodeA sending request 9 to all: org.infinispan.topology.HeartBeatCommand@1163beb6
> 14:29:19,986 TRACE (jgroups-6,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeC: SuccessfulResponse(null)
> 14:29:19,987 TRACE (jgroups-9,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeD: SuccessfulResponse(null)
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [TCP_NIO2] Test-NodeE: received message batch of 1 messages from Test-NodeA
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: message Test-NodeA::39 was added to queue (not yet server)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: received Test-NodeA#38
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: delivering Test-NodeA#38
> # not actually delivered :)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [MFC] Test-NodeA used 5 credits, 1999995 remaining
> 14:29:20,149 INFO (ForkThread-1,ForkChannelRestartTest:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:21,119 DEBUG (testng-Test-1:[]) [ForkChannelRestartTest] Stopping channel Test-NodeB
> 14:29:23,319 INFO (VERIFY_SUSPECT.TimerThread-32,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|5] (4) [Test-NodeA, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:23,320 TRACE (remote-thread-Test-NodeA-p2-t1:[]) [MultiTargetRequest] Target Test-NodeB of request 9 left the cluster view
> {noformat}
> So far, it looks like it's a JGroups bug similar to JGRP-2294, but we need to investigate further.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (ISPN-9836) RemoteCacheImpl.ping may hang when the server is stopped
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9836?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9836:
----------------------------------
Fix Version/s: 10.0.0.Beta1
(was: 10.0.0.Alpha3)
> RemoteCacheImpl.ping may hang when the server is stopped
> --------------------------------------------------------
>
> Key: ISPN-9836
> URL: https://issues.jboss.org/browse/ISPN-9836
> Project: Infinispan
> Issue Type: Bug
> Components: Server, Test Suite - Server
> Affects Versions: 10.0.0.Alpha2, 9.4.4.Final
> Reporter: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta1
>
> Attachments: RemoteStoreWrapperTest_infinispan-infinispan-cachestore-remote.log_20181218.log, threaddump-org_infinispan_persistence_remote_RemoteStoreWrapperTest_tearDown-2018-12-17-25284.log
>
>
> {{RemoteStoreWrapperTest.tearDown()}} first stops the server, then it stops the remote store connected to the server. Sometimes the store cannot be stopped because it is blocked in an availability check for > 5 min:
> {noformat}
> "testng-RemoteStoreWrapperTest" #14 prio=5 os_prio=0 tid=0x00007f1c74a1e000 nid=0x62e0 waiting on condition [0x00007f1c3cde4000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000c00028f8> (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.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.stop(PersistenceManagerImpl.java:214)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:181)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.performStop(BasicComponentRegistryImpl.java:599)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.stopWrapper(BasicComponentRegistryImpl.java:588)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.stop(BasicComponentRegistryImpl.java:461)
> at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:441)
> at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:376)
> at org.infinispan.cache.impl.CacheImpl.performImmediateShutdown(CacheImpl.java:1159)
> at org.infinispan.cache.impl.CacheImpl.stop(CacheImpl.java:1124)
> at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:520)
> at org.infinispan.manager.DefaultCacheManager.terminate(DefaultCacheManager.java:734)
> at org.infinispan.manager.DefaultCacheManager.stopCaches(DefaultCacheManager.java:786)
> at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:762)
> at org.infinispan.test.TestingUtil.killCacheManagers(TestingUtil.java:839)
> at org.infinispan.test.TestingUtil.killCacheManagers(TestingUtil.java:830)
> at org.infinispan.persistence.remote.RemoteStoreWrapperTest.tearDown(RemoteStoreWrapperTest.java:86)
> "persistence-thread-RemoteStoreWrapperTest-NodeB-p120-t1" #215 daemon prio=5 os_prio=0 tid=0x00007f1be128f000 nid=0x63b7 waiting on condition [0x00007f1bdd3d4000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000c40059a8> (a java.util.concurrent.CompletableFuture$Signaller)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1695)
> at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3323)
> at java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1775)
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915)
> at org.infinispan.client.hotrod.impl.Util.await(Util.java:21)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:542)
> at org.infinispan.persistence.remote.RemoteStore.isAvailable(RemoteStore.java:128)
> at org.infinispan.persistence.manager.PersistenceManagerImpl$StoreStatus.availabilityChanged(PersistenceManagerImpl.java:1252)
> - locked <0x00000000c00027e8> (a org.infinispan.persistence.manager.PersistenceManagerImpl$StoreStatus)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.pollStoreAvailability(PersistenceManagerImpl.java:194)
> at org.infinispan.persistence.manager.PersistenceManagerImpl$$Lambda$383/1386794082.run(Unknown Source)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (ISPN-9835) Jenkinsfile snapshot deployment fails
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9835?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9835:
----------------------------------
Fix Version/s: 10.0.0.Beta1
(was: 10.0.0.Alpha3)
> Jenkinsfile snapshot deployment fails
> -------------------------------------
>
> Key: ISPN-9835
> URL: https://issues.jboss.org/browse/ISPN-9835
> Project: Infinispan
> Issue Type: Bug
> Components: Build
> Affects Versions: 10.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> {noformat}
> 11:16:21.413 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-cli) on project infinispan-checkstyle: The packaging for this project did not assign a file to the build artifact -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-cli) on project infinispan-checkstyle: The packaging for this project did not assign a file to the build artifact
> {noformat}
> https://ci.infinispan.org/job/Infinispan/job/master/1005
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (ISPN-9844) DistSyncStoreNotSharedTest.clearContent sometimes hangs
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9844?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9844:
----------------------------------
Fix Version/s: 10.0.0.Beta1
(was: 10.0.0.Alpha3)
> 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)
7 years, 2 months
[JBoss JIRA] (ISPN-9845) Stop exposing InternalMetadata via the persistence SPI
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9845?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9845:
----------------------------------
Fix Version/s: 10.0.0.Beta1
(was: 10.0.0.Alpha3)
> Stop exposing InternalMetadata via the persistence SPI
> ------------------------------------------------------
>
> Key: ISPN-9845
> URL: https://issues.jboss.org/browse/ISPN-9845
> Project: Infinispan
> Issue Type: Sub-task
> Components: Loaders and Stores
> Affects Versions: 10.0.0.Alpha2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> We should stop exposing InternalMetadata via the persistence SPI and add created() methods direct to the MarshallableEntry interface introduced in ISPN-9693. This requires MarshallableEntry to change to:
> {code:java}
> interface MarshallableEntry<K, V> {
> ByteBuffer getKeyBytes();
> ByteBuffer getValueBytes();
> K getKey();
> V getValue();
> Metadata metadata();
> ByteBuffer metadataBytes();
> long created();
> long lastUsed();
> boolean isExpired(long now);
> long expiryTime();
> }
> {code}
> With MarshalledEntry then providing the old method for backwards compatiblity:
> {code:java}
> ByteBuffer getMetadataBytes();
> InternalMetadata getMetadata();
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months