[JBoss JIRA] (ISPN-2418) CLONE - Cache restart doesn't work properly
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-2418?page=com.atlassian.jira.plugin... ]
Dan Berindei closed ISPN-2418.
------------------------------
Fix Version/s: 8.2.0.Final
Resolution: Done
Fixed with ISPN-6286
> CLONE - Cache restart doesn't work properly
> -------------------------------------------
>
> Key: ISPN-2418
> URL: https://issues.redhat.com/browse/ISPN-2418
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.1.7.Final, 5.2.0.Alpha3
> Reporter: Dan Berindei
> Priority: Major
> Labels: jdg6
> Fix For: 8.2.0.Final
>
>
> Copied from ISPN-2297:
> {quote}
> If a cache is stopped via {{Cache.stop()}} it will still be returned by {{DefaultCacheManager.getCache()}}. Cache {{start()}} and {{stop()}} are not synchronized in any way, so a {{start()}} call may return before the cache was properly started - just because another thread is in the process of starting it.
> Also, the documentation of {{EmbeddedCacheManager.getCache()}} should say that it will start the cache only if it doesn't exist yet - if the cache is stopped it will return the cache as it was. Alternatively we could change the behaviour of {{getCache()}} to always start the cache.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-4348) Configuration parser loses <persistence/> element configuration
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-4348?page=com.atlassian.jira.plugin... ]
Dan Berindei resolved ISPN-4348.
--------------------------------
Fix Version/s: 7.0.0.Final
Resolution: Done
Fixed with ISPN-4153
> Configuration parser loses <persistence/> element configuration
> ---------------------------------------------------------------
>
> Key: ISPN-4348
> URL: https://issues.redhat.com/browse/ISPN-4348
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Loaders and Stores
> Affects Versions: 6.0.2.Final
> Reporter: Alexey Olenev
> Priority: Major
> Fix For: 7.0.0.Final
>
>
> I have a following configuration of named cache:
> <namedCache name="string-cache">
> <clustering mode="distribution">
> <sync />
> <stateTransfer fetchInMemoryState="true" />
> <hash numOwners="2" />
> </clustering>
> <persistence>
> <store class="org.sproot_grid.infinispan.cachestore.StringCacheStore"
> fetchPersistentState="false" ignoreModifications="false" purgeOnStartup="false">
> </store>
> </persistence>
> </namedCache>
> where StringCacheStore is my own implementation of CacheStore (implements AdvancedLoadWriteStore).
> I start cluster using constructor DefaultCacheManager(String configurationFile), but cache modifications don't trigger write-through because there is no stores in Configuration object.
> I investigated it in debug mode and found that configuration parser (Parser60) reads <store /> element but doesn't apply it to ConfigurationBuilder object if store is not an instance of SingleFileStore or ClusterLoader, so it means that I can't configure my custom CacheStore
> This is a copy of my stack during configuration reading:
> Thread [main] (Suspended (breakpoint at line 640 in Parser60))
> Parser60.parseStore(XMLExtendedStreamReader, ConfigurationBuilderHolder) line: 640
> Parser60.parsePersistence(XMLExtendedStreamReader, ConfigurationBuilderHolder) line: 555
> Parser60.parseCache(XMLExtendedStreamReader, ConfigurationBuilderHolder) line: 150
> Parser60.parseNamedCache(XMLExtendedStreamReader, ConfigurationBuilderHolder) line: 109
> Parser60.readElement(XMLExtendedStreamReader, ConfigurationBuilderHolder) line: 76
> ParserRegistry.parseElement(XMLExtendedStreamReader, ConfigurationBuilderHolder) line: 141
> ParserRegistry.parse(XMLExtendedStreamReader, ConfigurationBuilderHolder) line: 123
> ParserRegistry.parse(InputStream, ConfigurationBuilderHolder) line: 110
> ParserRegistry.parse(InputStream) line: 97
> DefaultCacheManager.<init>(InputStream, boolean) line: 253
> DefaultCacheManager.<init>(String, boolean) line: 226
> DefaultCacheManager.<init>(String) line: 213
> ClusterFacade.init() line: 48
> ClusterFacade.getFacade() line: 41
> ClusterFacadeTest.initCluster() line: 21
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: 57
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
> Method.invoke(Object, Object...) line: 601
> FrameworkMethod$1.runReflectiveCall() line: 44
> FrameworkMethod$1(ReflectiveCallable).run() line: 15
> FrameworkMethod.invokeExplosively(Object, Object...) line: 41
> RunBefores.evaluate() line: 27
> BlockJUnit4ClassRunner(ParentRunner<T>).run(RunNotifier) line: 236
> JUnit4TestMethodReference(JUnit4TestReference).run(TestExecution) line: 50
> TestExecution.run(ITestReference[]) line: 38
> RemoteTestRunner.runTests(String[], String, TestExecution) line: 467
> RemoteTestRunner.runTests(TestExecution) line: 683
> RemoteTestRunner.run() line: 390
> RemoteTestRunner.main(String[]) line: 197
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-2395) Key sorting done by the OptimisticLockingInterceptor is incompatible with the lock striping
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-2395?page=com.atlassian.jira.plugin... ]
Dan Berindei closed ISPN-2395.
------------------------------
Fix Version/s: 8.0.0.Final
Resolution: Out of Date
Since ISPN-2849 {{DefaultLockManager}} acquires all of a transaction's keys atomically, so the sorting doesn't matter any more.
> Key sorting done by the OptimisticLockingInterceptor is incompatible with the lock striping
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-2395
> URL: https://issues.redhat.com/browse/ISPN-2395
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.5.FINAL, 5.1.6.FINAL, 5.1.7.Final, 5.2.0.Beta1
> Reporter: Nicolas Filotto
> Priority: Minor
> Fix For: 8.0.0.Final
>
> Attachments: TestLocking.java
>
>
> In ISPN 5.0, you provided a workaround allowing us to sort the keys ourself in order to prevent deadlocks even in case we enable the lock striping (more details here ISPN-993), thanks to this workaround we could write a simple key comparator (that works with lock striping enabled or not) as next:
> {code}
> public int compare(Object k1, Object k2) {
> LockManager lm = cache.getLockManager();
> int result = lm.getLockId(key1) - lm.getLockId(k2);
> }
> {code}
> Starting from ISPN 5.1 (ISPN-1132), the keys are sorted automatically by ISPN however unfortunately what has been done is incompatible with lock striping, indeed the keys are sorted regardless the lock distribution which is a mistake since we actually expect the keys to be sorted according to the corresponding locks and not to the keys themselves otherwise deadlock can still occur.
> As attached file, you will find a test case that shows the issue.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-8724) Server hangs during stop
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-8724?page=com.atlassian.jira.plugin... ]
Dan Berindei closed ISPN-8724.
------------------------------
Fix Version/s: 11.0.0.Alpha2
Resolution: Out of Date
The test was removed with ISPN-10594
> Server hangs during stop
> ------------------------
>
> Key: ISPN-8724
> URL: https://issues.redhat.com/browse/ISPN-8724
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.0.CR1
> Reporter: Gustavo Fernandes
> Priority: Critical
> Fix For: 11.0.0.Alpha2
>
> Attachments: s1, s2, test
>
>
> This was observed during the execution of test {{HotRodRemoteStreamingIT}}, Line 499 on method stopServer().
> The surefire process waits forever for the two servers to stop.
> One of the servers is waiting for the initial state transfer to complete:
> {noformat}
> "Thread-48" #95 prio=5 os_prio=0 tid=0x00007fdaf48f69f0 nid=0x590a waiting on condition [0x00007fdae1a26000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000ee8cfc00> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:231)
> 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.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
> at org.infinispan.commons.util.SecurityActions$$Lambda$170/1509149284.run(Unknown Source)
> at org.infinispan.commons.util.SecurityActions.doPrivileged(SecurityActions.java:71)
> at org.infinispan.commons.util.SecurityActions.invokeAccessibly(SecurityActions.java:76)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:968)
> at org.infinispan.factories.AbstractComponentRegistry.lambda$invokePrioritizedMethods$6(AbstractComponentRegistry.java:703)
> at org.infinispan.factories.AbstractComponentRegistry$$Lambda$175/1225674479.run(Unknown Source)
> at org.infinispan.factories.SecurityActions.lambda$run$1(SecurityActions.java:72)
> at org.infinispan.factories.SecurityActions$$Lambda$176/1784470267.run(Unknown Source)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.factories.SecurityActions.run(SecurityActions.java:71)
> at org.infinispan.factories.AbstractComponentRegistry.invokePrioritizedMethods(AbstractComponentRegistry.java:696)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:689)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:607)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:228)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:962)
> at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:411)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:637)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:582)
> at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:468)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:454)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
> at org.infinispan.counter.impl.CounterModuleLifecycle.lambda$startCaches$0(CounterModuleLifecycle.java:132)
> at org.infinispan.counter.impl.CounterModuleLifecycle$$Lambda$194/218224883.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The other server is running a series of operations after the server stops, such
> as {{EmbeddedCacheManager#undefineConfiguration}}, this can be seen on 3 threads:
> MSC service thread 1-1, MSC service thread 1-2 and MSC service thread 1-3
> {noformat}
> "MSC service thread 1-1" #12 prio=5 os_prio=0 tid=0x00007fd4e86720a0 nid=0x56f1 waiting on condition [0x00007fd4bc8f2000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fb922a18> (a java.util.concurrent.CompletableFuture$Signaller)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1693)
> at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3323)
> at java.util.concurrent.CompletableFuture.waitingGet(CompletableFuture.java:1729)
> at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1934)
> at org.infinispan.manager.DefaultCacheManager.undefineConfiguration(DefaultCacheManager.java:394)
> at org.infinispan.security.actions.UndefineConfigurationAction.run(UndefineConfigurationAction.java:25)
> at org.infinispan.security.actions.UndefineConfigurationAction.run(UndefineConfigurationAction.java:13)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.registry.impl.SecurityActions.undefineConfiguration(SecurityActions.java:39)
> at org.infinispan.registry.impl.InternalCacheRegistryImpl.unregisterInternalCache(InternalCacheRegistryImpl.java:77)
> - locked <0x00000000ee2e1420> (a org.infinispan.registry.impl.InternalCacheRegistryImpl)
> at org.infinispan.server.hotrod.HotRodServer.stop(HotRodServer.java:486)
> at org.infinispan.server.endpoint.subsystem.ProtocolServerService.doStop(ProtocolServerService.java:216)
> at org.infinispan.server.endpoint.subsystem.ProtocolServerService.stop(ProtocolServerService.java:206)
> - locked <0x00000000edd0eae0> (a org.infinispan.server.endpoint.subsystem.ProtocolServerService)
> 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:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> For some reason, also in the other server, the CounterModule lifecycle is reacting to a
> cache manager start event, and it's hanged as well:
> {noformat}
> "Thread-48" #95 prio=5 os_prio=0 tid=0x00007fd4986a2090 nid=0x575b waiting on condition [0x00007fd48f2f4000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000ee91b048> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:231)
> 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.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
> at org.infinispan.commons.util.SecurityActions$$Lambda$170/1758042552.run(Unknown Source)
> at org.infinispan.commons.util.SecurityActions.doPrivileged(SecurityActions.java:71)
> at org.infinispan.commons.util.SecurityActions.invokeAccessibly(SecurityActions.java:76)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:968)
> at org.infinispan.factories.AbstractComponentRegistry.lambda$invokePrioritizedMethods$6(AbstractComponentRegistry.java:703)
> at org.infinispan.factories.AbstractComponentRegistry$$Lambda$175/1042194083.run(Unknown Source)
> at org.infinispan.factories.SecurityActions.lambda$run$1(SecurityActions.java:72)
> at org.infinispan.factories.SecurityActions$$Lambda$176/2118421355.run(Unknown Source)
> at org.infinispan.security.Security.doPrivileged(Security.java:76)
> at org.infinispan.factories.SecurityActions.run(SecurityActions.java:71)
> at org.infinispan.factories.AbstractComponentRegistry.invokePrioritizedMethods(AbstractComponentRegistry.java:696)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:689)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:607)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:228)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:962)
> at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:411)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:637)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:582)
> at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:468)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:454)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
> at org.infinispan.counter.impl.CounterModuleLifecycle.lambda$startCaches$0(CounterModuleLifecycle.java:132)
> at org.infinispan.counter.impl.CounterModuleLifecycle$$Lambda$194/1023465788.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-11465) Upgrade to JGroups 4.2.1.Final
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11465?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11465:
--------------------------------
Status: Open (was: New)
> Upgrade to JGroups 4.2.1.Final
> ------------------------------
>
> Key: ISPN-11465
> URL: https://issues.redhat.com/browse/ISPN-11465
> Project: Infinispan
> Issue Type: Component Upgrade
> Components: Dependency
> Affects Versions: 11.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Dev03
>
>
> JGroups 4.2.1 includes a fix for JGRP-2435, which should fix the random failure in {{InitialClusterSizeTest}}.
> JGRP-2451 also adds a new failure detection protocol, {{FD3_ALL}}, which doesn't need extra heartbeats as long as the nodes are sending other broadcast messages.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-11127) Protocol servers don't pre-start caches when transport is disabled
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11127?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11127:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 11.0.0.Dev03
Resolution: Done
> Protocol servers don't pre-start caches when transport is disabled
> ------------------------------------------------------------------
>
> Key: ISPN-11127
> URL: https://issues.redhat.com/browse/ISPN-11127
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.1.0.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 11.0.0.Dev03, 10.1.5.Final
>
>
> The various protocol servers have different initialization steps to ensures that caches are pre-started which don't work in all cases. In particular the REST server doesn't pre-start caches and the Hot Rod server pre-starts only if the transport is enabled.
> This should be handled uniformly.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years