[JBoss JIRA] (ISPN-6368) Race condition in InternalCacheRegistryImpl.registerInternalCache
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6368?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-6368.
-------------------------------------
> Race condition in InternalCacheRegistryImpl.registerInternalCache
> -----------------------------------------------------------------
>
> Key: ISPN-6368
> URL: https://issues.jboss.org/browse/ISPN-6368
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 8.1.3.Final, 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final
>
>
> Access to internalCaches set can cause race conditions and errors related to duplicate cache definitions can be mistakenly reported.
> {code}
> 17:51:40,668 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.datagrid-infinispan.clustered.disttestcache: org.jboss.msc.service.StartException in service jboss.datagrid-infinispan.clustered.disttestcache: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000358: A cache configuration named ___query_known_classes already exists. This cannot be configured externally by the user.
> at org.infinispan.registry.impl.InternalCacheRegistryImpl.registerInternalCache(InternalCacheRegistryImpl.java:56)
> at org.infinispan.registry.impl.InternalCacheRegistryImpl.registerInternalCache(InternalCacheRegistryImpl.java:49)
> at org.infinispan.query.backend.QueryKnownClasses.startInternalCache(QueryKnownClasses.java:219)
> at org.infinispan.query.backend.QueryKnownClasses.start(QueryKnownClasses.java:119)
> at org.infinispan.query.backend.QueryInterceptor.start(QueryInterceptor.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:859)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:628)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:617)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:542)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:238)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:849)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:635)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:585)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:451)
> at org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager.getCache(AbstractDelegatingEmbeddedCacheManager.java:133)
> at org.infinispan.server.infinispan.SecurityActions$5.run(SecurityActions.java:130)
> at org.infinispan.server.infinispan.SecurityActions$5.run(SecurityActions.java:127)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:63)
> at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:135)
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:86)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ISPN-6414) Hybrid query + compat mode applies type conversion too early (perf issue)
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6414?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-6414.
-------------------------------------
> Hybrid query + compat mode applies type conversion too early (perf issue)
> -------------------------------------------------------------------------
>
> Key: ISPN-6414
> URL: https://issues.jboss.org/browse/ISPN-6414
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 8.2.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final
>
>
> To reproduce we need a compat mode cache and a remote hybrid query or any query that is executed in two phases (indexed + non indexed). The type conversion interceptor will convert the result of the first phase (from Java object to protobuf) and then the second phase will execute a matcher on the protobuf output of the first phase.
> This can be optimized by avoiding early type conversion. The output of the first phase should produce unconverted results, ie. java objects. Then the second phase matcher should filter on these objects (ReflectionMatcher). These results are then implicitly type-converted when are marshalled back to the client, but the type converter interceptor is no longer involved. To avoid type conversion kicking in early we need to stop obtaining the cache using the Flag.OPERATION_HOTROD in org.infinispan.query.remote.impl.LifecycleManager, and then there are some other places in RemoteQueryEngine and friends that need to be adjusted following this change.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ISPN-6341) StateTransferManager should be the first component to stop
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6341?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-6341.
-------------------------------------
> StateTransferManager should be the first component to stop
> ----------------------------------------------------------
>
> Key: ISPN-6341
> URL: https://issues.jboss.org/browse/ISPN-6341
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.2.1.Final, 9.0.0.Alpha1
>
>
> When a cache stops, it first removes the component registry from the {{GlobalComponentsRegistry}}'s {{namedComponents}} map, which means the node (let's call it {{A}}) will reply with a {{CacheNotFoundResponse}} to any remote command.
> Another node {{B}} trying to execute a write/transactional command will receive the {{CacheNotFoundResponse}}, assume that a new cache topology with id {{current topology id + 1}} is coming soon, and wait for that new topology before retrying.
> Normally this is not a problem, because {{StateTransferManagerImpl.stop()}} sends a {{CacheTopologyControlCommand(LEAVE)}} to the coordinator quickly enough, then {{B}} receives the {{current topology id + 1}} topology and retries the command.
> But in some cases, the cache components that stop before {{StateTransferManagerImpl}} can take a long time to do so. In particular, because of {{ISPN-5507}}, {{TransactionTable}} can block for {{cacheStopTimeout}} if there are remote transactions in progress, even though the cache can no longer process remote commands.
> We should give {{StateTransferManagerImpl.stop()}} a priority of {{0}}, so that the {{CacheTopologyControlCommand(LEAVE)}} comand is sent as soon as possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ISPN-6425) FileNotFoundException with async indexing backend
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6425?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-6425.
-------------------------------------
> FileNotFoundException with async indexing backend
> -------------------------------------------------
>
> Key: ISPN-6425
> URL: https://issues.jboss.org/browse/ISPN-6425
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Lucene Directory
> Affects Versions: 8.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final
>
>
> The Infinispan directory defaults to {{write_metadata_async=true}} when the indexing backend is configured as async, i.e. {{default.worker.execution}} is {{true}}.
> The {{write_metadata_async=true}} will use {{cache.putAsync}} to write the index file metadata, while still deleting and creating files syncronously. This can lead to
> a stale metadata causing FileNotFoundExceptions when executing queries:
> Suppose a lucene directory contains files \[segments_4, _4.si\]. During normal regime, apart from the user thread, there could be other 2 threads that could be changing the index, the periodic commit thread (since backend is async) and the async deletion of files.
> The following race can happen:
> ||Time||Thread||work type||work||
> |T1|Hibernate Search: Commit Scheduler for index| SYNC | write files segments_5 and _5.si to the index
> |T2|Hibernate Search: Commit Scheduler for index| ASYNC | write the new file list containing \[segments_4, _4.si, segments_5,_5.si\]
> |T3|Hibernate Search: Commit Scheduler for index| ASYNC | enqueue a deletion task for files segments_4 and _4.si
> |T4|Hibernate Search: async deletion of index| SYNC | dequeue deletion task for files segments_4 and _4.si
> |T5|Hibernate Search: async deletion of index| SYNC | delete files segments_4 and _4.si from the index
> |T6|Hibernate Search: async deletion of index| ASYNC | write the new file list containing \[segments_5,_5.si\]
> |T7|User-thread| |open index reader, file list is \[segments_4, _4.si\], highest segment number is 4 (file list is not updated yet)
> |T8|User-thread| |open segments_4
> |T9|User-thread| |FileNotFoundException!
> |T10|remote-thread-User| | new file list received \[segments_4, _4.si, segments_5,_5.si\]
> |T11|remote-thread-User| | new file list received \[segments_5,_5.si\]
> This race can be observed in {{MassIndexerAsyncBackendTest#testMassIndexOnAsync}} that fails intermittently with the exception:
> {noformat}
> Caused by: java.io.FileNotFoundException: Error loading metadata for index file: M|segments_4|commonIndex|-1
> at org.infinispan.lucene.impl.DirectoryImplementor.openInput(DirectoryImplementor.java:138) ~[infinispan-lucene-directory-9.0.0-SNAPSHOT.jar:9.0.0-SNAPSHOT]
> at org.infinispan.lucene.impl.DirectoryLucene.openInput(DirectoryLucene.java:102) ~[infinispan-lucene-directory-9.0.0-SNAPSHOT.jar:9.0.0-SNAPSHOT]
> at org.apache.lucene.store.Directory.openChecksumInput(Directory.java:109) ~[lucene-core-5.5.0.jar:5.5.0 2a228b3920a07f930f7afb6a42d0d20e184a943c - mike - 2016-02-16 15:18:34]
> at org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:294) ~[lucene-core-5.5.0.jar:5.5.0 2a228b3920a07f930f7afb6a42d0d20e184a943c - mike - 2016-02-16 15:18:34]
> at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:493) ~[lucene-core-5.5.0.jar:5.5.0 2a228b3920a07f930f7afb6a42d0d20e184a943c - mike - 2016-02-16 15:18:34]
> at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:490) ~[lucene-core-5.5.0.jar:5.5.0 2a228b3920a07f930f7afb6a42d0d20e184a943c - mike - 2016-02-16 15:18:34]
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:731) ~[lucene-core-5.5.0.jar:5.5.0 2a228b3920a07f930f7afb6a42d0d20e184a943c - mike - 2016-02-16 15:18:34]
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:683) ~[lucene-core-5.5.0.jar:5.5.0 2a228b3920a07f930f7afb6a42d0d20e184a943c - mike - 2016-02-16 15:18:34]
> at org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:490) ~[lucene-core-5.5.0.jar:5.5.0 2a228b3920a07f930f7afb6a42d0d20e184a943c - mike - 2016-02-16 15:18:34]
> at org.apache.lucene.index.StandardDirectoryReader.isCurrent(StandardDirectoryReader.java:344) ~[lucene-core-5.5.0.jar:5.5.0 2a228b3920a07f930f7afb6a42d0d20e184a943c - mike - 2016-02-16 15:18:34]
> at org.apache.lucene.index.StandardDirectoryReader.doOpenNoWriter(StandardDirectoryReader.java:300) ~[lucene-core-5.5.0.jar:5.5.0 2a228b3920a07f930f7afb6a42d0d20e184a943c - mike - 2016-02-16 15:18:34]
> at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:263) ~[lucene-core-5.5.0.jar:5.5.0 2a228b3920a07f930f7afb6a42d0d20e184a943c - mike - 2016-02-16 15:18:34]
> at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:251) ~[lucene-core-5.5.0.jar:5.5.0 2a228b3920a07f930f7afb6a42d0d20e184a943c - mike - 2016-02-16 15:18:34]
> {noformat}
> We should not enable {{write_metadata_async=true}} for async backends. The file list is already {{DeltaAware}}, so writing should not pose a meaningfull overhead when done synchronously.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ISPN-6356) SecurityException during HotRod server stop
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6356?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-6356.
-------------------------------------
> SecurityException during HotRod server stop
> -------------------------------------------
>
> Key: ISPN-6356
> URL: https://issues.jboss.org/browse/ISPN-6356
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.2.0.Final
> Reporter: Dan Berindei
> Assignee: Vojtech Juranek
> Fix For: 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final
>
>
> The HotRod server should use a SecurityAction to remove the `CrashedMemberDetectorListener` listener (and probably to remove the `ReAddMyAddressListener` listener as well).
> {noformat}
> 20:41:29,066 WARN [org.infinispan.server.endpoint] (MSC service thread 1-7) DGENDPT10010: Failed to stop connector HotRodServer: java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'null' lacks 'LISTEN' permission
> at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:86)
> at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:56)
> at org.infinispan.manager.DefaultCacheManager.removeListener(DefaultCacheManager.java:727)
> at org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager.removeListener(AbstractDelegatingEmbeddedCacheManager.java:193)
> at org.infinispan.server.hotrod.HotRodServer.stop(HotRodServer.scala:310)
> at org.infinispan.server.endpoint.subsystem.ProtocolServerService.doStop(ProtocolServerService.java:199)
> at org.infinispan.server.endpoint.subsystem.ProtocolServerService.stop(ProtocolServerService.java:189)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ISPN-6460) Race condition during server start causes wrong configuration to be used for cache 'default'
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6460?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-6460.
-------------------------------------
> Race condition during server start causes wrong configuration to be used for cache 'default'
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-6460
> URL: https://issues.jboss.org/browse/ISPN-6460
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.2.0.Final, 8.1.2.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 8.1.3.Final, 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final
>
>
> The rest endpoint subsystem forces the startup of the "default" cache, whose configuration might not yet be read from the server xml and defined in the cache manager.
> As a result, the "default" cache will be started with a LOCAL configuration, and will never use the right configuration again. This can cause side effects such as the cache topology is not sent during a PingRequest (since cache is configured as LOCAL), also potentially ClearCommand failing with NPE since the default cache configuration is LOCAL in one node and clustered on another.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ISPN-6098) LockManagerTest.testMultipleCounterStripped random failures
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6098?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-6098.
-------------------------------------
> LockManagerTest.testMultipleCounterStripped random failures
> -----------------------------------------------------------
>
> Key: ISPN-6098
> URL: https://issues.jboss.org/browse/ISPN-6098
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Fix For: 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final
>
> Attachments: LockManagerTest_ISPN-3305_remove_lock_reordering_tests_20160324.log.gz
>
>
> Doesn't appear to fail in CI, but I did get a couple failures running the test on my machine:
> {noformat}
> 17:42:29,998 ERROR (testng-LockManagerTest:) [UnitTestTestNGListener] Test testMultipleCounterStripped(org.infinispan.lock.LockManagerTest) failed.
> java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 60 seconds for key key-6 and requestor Thread[pool-1127-thread-4,5,main]. Lock is held by null
> at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_60]
> at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_60]
> at org.infinispan.lock.LockManagerTest.doMultipleCounterTest(LockManagerTest.java:193) ~[test-classes/:?]
> at org.infinispan.lock.LockManagerTest.testMultipleCounterStripped(LockManagerTest.java:67) ~[test-classes/:?]
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 60 seconds for key key-6 and requestor Thread[pool-1127-thread-4,5,main]. Lock is held by null
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236) ~[classes/:?]
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$CompositeLockPromise.lock(DefaultLockManager.java:305) ~[classes/:?]
> at org.infinispan.lock.LockManagerTest.lambda$doMultipleCounterTest$483(LockManagerTest.java:163) ~[test-classes/:?]
> ... 4 more
> {noformat}
> In another run, I got a deadlock that I think is related in {{InfinispanLockTest}}:
> {noformat}
> "testng-InfinispanLockTest" #19 prio=5 os_prio=0 tid=0x00007ff7f0eeb800 nid=0x4f5d waiting on condition [0x00007ff770da5000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0000000084202448> (a java.util.concurrent.FutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at org.infinispan.lock.InfinispanLockTest.testSingleCounter(InfinispanLockTest.java:262)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> 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:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Locked ownable synchronizers: - <0x0000000082875cc0> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "pool-1011-thread-7" #9840 prio=5 os_prio=0 tid=0x00007ff7380da000 nid=0x75f7 waiting on condition [0x00007ff698409000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000842020d8> (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.util.concurrent.CompletableFutures.await(CompletableFutures.java:74)
> at org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.lock(InfinispanLock.java:319)
> at org.infinispan.lock.InfinispanLockTest.lambda$testSingleCounter$509(InfinispanLockTest.java:243)
> at org.infinispan.lock.InfinispanLockTest$$Lambda$516/1905052434.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Locked ownable synchronizers: - <0x00000000842021f8> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "pool-1011-thread-6" #9839 prio=5 os_prio=0 tid=0x00007ff738130800 nid=0x75f6 waiting on condition [0x00007ff699c21000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000842023a0> (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.util.concurrent.CompletableFutures.await(CompletableFutures.java:74)
> at org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.lock(InfinispanLock.java:319)
> at org.infinispan.lock.InfinispanLockTest.lambda$testSingleCounter$509(InfinispanLockTest.java:243)
> at org.infinispan.lock.InfinispanLockTest$$Lambda$516/1905052434.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Locked ownable synchronizers: - <0x0000000084202468> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {noformat}
> I also suggest using {{AbstractInfinispanTest.fork()}} instead of an explicit {{ExecutorService}} in both tests, because without the test name in the thread name it's impossible to filter the test logs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ISPN-6398) Duplicate infinispan-tasks dependency in infinispan-server-infinispan POM
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6398?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-6398.
-------------------------------------
> Duplicate infinispan-tasks dependency in infinispan-server-infinispan POM
> -------------------------------------------------------------------------
>
> Key: ISPN-6398
> URL: https://issues.jboss.org/browse/ISPN-6398
> Project: Infinispan
> Issue Type: Bug
> Components: Build process, Server
> Affects Versions: 8.2.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Trivial
> Fix For: 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final
>
>
> {noformat}
> [WARNING] Some problems were encountered while building the effective model for org.infinispan.server:infinispan-server-infinispan:jar:9.0.0-SNAPSHOT
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: org.infinispan:infinispan-tasks:jar -> version (?) vs ${version.org.infinispan} @ org.infinispan.server:infinispan-server-infinispan:[unknown-version], /tmp/privatebuild/infinispan/server/integration/infinispan/pom.xml, line 137, column 21
> {noformat}
> {noformat}
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-tasks</artifactId>
> </dependency>
> ...
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-tasks</artifactId>
> <version>${version.org.infinispan}</version>
> </dependency>
> {noformat}
> The version should be specified in the infinispan-server-versions POM.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ISPN-6373) Cache stop order not respected for ShardIndexManager
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6373?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-6373.
-------------------------------------
> Cache stop order not respected for ShardIndexManager
> ----------------------------------------------------
>
> Key: ISPN-6373
> URL: https://issues.jboss.org/browse/ISPN-6373
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 8.2.1.Final, 9.0.0.Alpha1, 9.0.0.Final
>
>
> Query test suite is throwing tons of
> {noformat} ISPN000323: Cache 'LuceneIndexesLocking' is in 'TERMINATED' state and so it does not accept new invocations. Either restart it or recreate the cache container.
> {noformat}
> for test {{ClusteredCacheWithShardedIndexManagerTest}} since stop dependencies are not added correctly during initialization.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years