March 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6869) Deadlock during stopping CacheManager

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-6869?page=com.atlassian.jira.plugin.... ] Vojtech Juranek updated ISPN-6869: ---------------------------------- Status: Open (was: Pull Request Sent) > Deadlock during stopping CacheManager > ------------------------------------- > > Key: ISPN-6869 > URL: https://issues.jboss.org/browse/ISPN-6869 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Alpha3 > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Attachments: server.log.gz > > > When new cache is started during ISPN shutdown, it can result into a deadlock. > When new cache is created, first {{DefaultCacheManager.CacheWrapper}} is created with a latch. This latch is release once cache is fully started. If in meantime {{DefaultCacheManager#stop}} is called, it will first stop and lock {{GlobalComponentRegistry}} and after that will try to access and stop all caches. However, if there is present half-created cache (one with latch in {{DefaultCacheManager.CacheWrapper}} not released yet), if will result into a deadlock, as {{cache#start}} tries to access and lock {{GlobalComponentRegistry}}, already lock by {{DefaultCacheManager}}. > Relevant pieces of stack traces are bellow, whole stack trace is attached. > Locking of {{GlobalComponentRegistry}} by {{DefaultCacheManager#stop}}: > {noformat} > at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:569) > - locked <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry) > at org.infinispan.factories.GlobalComponentRegistry.stop(GlobalComponentRegistry.java:282) > - locked <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry) > at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:699) > - locked <0x00000000e1606bb0> (a org.infinispan.manager.DefaultCacheManager) > at org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager.stop(AbstractDelegatingEmbeddedCacheManager.java:173) > {noformat} > and later of waiting for cache latch: > {noformat} > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000fd59db80> (a java.util.concurrent.CountDownLatch$Sync) > 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.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at org.infinispan.manager.DefaultCacheManager$CacheWrapper.getCache(DefaultCacheManager.java:968) > {noformat} > Waiting for a lock for {{GlobalComponentRegistry}} when cache is created: > {noformat} > at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277) > - waiting to lock <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry) > at org.infinispan.factories.GlobalComponentRegistry.getTimeService(GlobalComponentRegistry.java:167) > at org.infinispan.factories.ComponentRegistry.getTimeService(ComponentRegistry.java:271) > at org.infinispan.distexec.DefaultExecutorService.<init>(DefaultExecutorService.java:190) > [...] > org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:636) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:587) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:452) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:438) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6869) Deadlock during stopping CacheManager

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-6869?page=com.atlassian.jira.plugin.... ] Vojtech Juranek updated ISPN-6869: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4459, https://github.com/infinispan/infinispan/pull/4929 (was: https://github.com/infinispan/infinispan/pull/4459) > Deadlock during stopping CacheManager > ------------------------------------- > > Key: ISPN-6869 > URL: https://issues.jboss.org/browse/ISPN-6869 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Alpha3 > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Attachments: server.log.gz > > > When new cache is started during ISPN shutdown, it can result into a deadlock. > When new cache is created, first {{DefaultCacheManager.CacheWrapper}} is created with a latch. This latch is release once cache is fully started. If in meantime {{DefaultCacheManager#stop}} is called, it will first stop and lock {{GlobalComponentRegistry}} and after that will try to access and stop all caches. However, if there is present half-created cache (one with latch in {{DefaultCacheManager.CacheWrapper}} not released yet), if will result into a deadlock, as {{cache#start}} tries to access and lock {{GlobalComponentRegistry}}, already lock by {{DefaultCacheManager}}. > Relevant pieces of stack traces are bellow, whole stack trace is attached. > Locking of {{GlobalComponentRegistry}} by {{DefaultCacheManager#stop}}: > {noformat} > at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:569) > - locked <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry) > at org.infinispan.factories.GlobalComponentRegistry.stop(GlobalComponentRegistry.java:282) > - locked <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry) > at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:699) > - locked <0x00000000e1606bb0> (a org.infinispan.manager.DefaultCacheManager) > at org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager.stop(AbstractDelegatingEmbeddedCacheManager.java:173) > {noformat} > and later of waiting for cache latch: > {noformat} > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000fd59db80> (a java.util.concurrent.CountDownLatch$Sync) > 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.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at org.infinispan.manager.DefaultCacheManager$CacheWrapper.getCache(DefaultCacheManager.java:968) > {noformat} > Waiting for a lock for {{GlobalComponentRegistry}} when cache is created: > {noformat} > at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277) > - waiting to lock <0x00000000e1606fc0> (a org.infinispan.factories.GlobalComponentRegistry) > at org.infinispan.factories.GlobalComponentRegistry.getTimeService(GlobalComponentRegistry.java:167) > at org.infinispan.factories.ComponentRegistry.getTimeService(ComponentRegistry.java:271) > at org.infinispan.distexec.DefaultExecutorService.<init>(DefaultExecutorService.java:190) > [...] > org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:636) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:587) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:452) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:438) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7553) Replicated cache with numOwners=1 doesn't send writes to backups

by Dan Berindei (JIRA)

Dan Berindei created ISPN-7553: ---------------------------------- Summary: Replicated cache with numOwners=1 doesn't send writes to backups Key: ISPN-7553 URL: https://issues.jboss.org/browse/ISPN-7553 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.0.0.CR2 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Critical Fix For: 9.0.0.Final {{BaseDistributionInterceptor.primaryReturnHandler()}} doesn't replicate writes to the backups if {{cacheConfiguration.clustering().hash().numOwners() == 1}}. That check is incorrect, because a segment can have more owners than configured: 1. In a replicated cache, the configured {{numOwners}} is ignored, and all the members are owners. 1. Even in a distributed cache, during rebalance, the segments being moved will have more than {{numOwners}} owners. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7544) Administration console - server cards do not indicate correct status in some cases

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7544?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-7544. -------------------------------- Fix Version/s: 9.0.0.Final Assignee: Vladimir Blagojevic Resolution: Done > Administration console - server cards do not indicate correct status in some cases > ---------------------------------------------------------------------------------- > > Key: ISPN-7544 > URL: https://issues.jboss.org/browse/ISPN-7544 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.Final > > > Server cards (clusters tab -> cluster) don't indicate that the server is in reload-required, restart required state. - they show green check icon in this case. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7469) Administration console - JDBC store elements have the same IDs

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7469?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-7469: ------------------------------- Summary: Administration console - JDBC store elements have the same IDs (was: Administration console - some elements have the same IDs) > Administration console - JDBC store elements have the same IDs > -------------------------------------------------------------- > > Key: ISPN-7469 > URL: https://issues.jboss.org/browse/ISPN-7469 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR1 > Reporter: Roman Macor > Assignee: Ryan Emerson > > Some elements have the same IDs. > Steps to reproduce: > Click on cache container -> cache -> configuration -> store -> select String keyed JDBC store -> click on String keyed table -> several input elements have the same ID -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7552) Rolling Upgrade enhancements

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7552?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7552: ------------------------------------ Description: The rolling upgrade can migrate data between clusters with no downtime, but currently the procedure is somehow complicated. Some proposals to improve it: * Provide scripts to automate the procedure * Provide pre-canned configurations to start the new cluster or scripts to automate the remote cache store addition * Server initiated cluster switch: the server would send a new topology to clients so that manual shutdown, change config and startup is not necessary Others? was: The rolling upgrade can migrate data between clusters with no downtime, but currently the procedure is somehow complicated. Some proposals to improve it: * Provide scripts to automate the procedure * Provide pre-canned configurations to start the new cluster * Server initiated cluster switch: the server would send a new topology to clients so that manual shutdown, change config and startup is not necessary Others? > Rolling Upgrade enhancements > ---------------------------- > > Key: ISPN-7552 > URL: https://issues.jboss.org/browse/ISPN-7552 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Gustavo Fernandes > > The rolling upgrade can migrate data between clusters with no downtime, but currently the procedure is somehow complicated. > Some proposals to improve it: > * Provide scripts to automate the procedure > * Provide pre-canned configurations to start the new cluster or scripts to automate the remote cache store addition > * Server initiated cluster switch: the server would send a new topology to clients so that manual shutdown, change config and startup is not necessary > Others? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7469) Administration console - JDBC store elements have the same IDs

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7469?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-7469: ------------------------------- Status: Open (was: New) > Administration console - JDBC store elements have the same IDs > -------------------------------------------------------------- > > Key: ISPN-7469 > URL: https://issues.jboss.org/browse/ISPN-7469 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR1 > Reporter: Roman Macor > Assignee: Ryan Emerson > > Some elements have the same IDs. > Steps to reproduce: > Click on cache container -> cache -> configuration -> store -> select String keyed JDBC store -> click on String keyed table -> several input elements have the same ID -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7469) Administration console - JDBC store elements have the same IDs

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7469?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-7469: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-management-console/pull/197 > Administration console - JDBC store elements have the same IDs > -------------------------------------------------------------- > > Key: ISPN-7469 > URL: https://issues.jboss.org/browse/ISPN-7469 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR1 > Reporter: Roman Macor > Assignee: Ryan Emerson > > Some elements have the same IDs. > Steps to reproduce: > Click on cache container -> cache -> configuration -> store -> select String keyed JDBC store -> click on String keyed table -> several input elements have the same ID -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7552) Rolling Upgrade enhancements

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7552?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7552: ------------------------------------ Summary: Rolling Upgrade enhancements (was: Rolling Upgrade enhancement) > Rolling Upgrade enhancements > ---------------------------- > > Key: ISPN-7552 > URL: https://issues.jboss.org/browse/ISPN-7552 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Gustavo Fernandes > > The rolling upgrade can migrate data between clusters with no downtime, but currently the procedure is somehow complicated. > Some proposals to improve it: > * Provide scripts to automate the procedure > * Provide pre-canned configurations to start the new cluster > * Server initiated cluster switch: the server would send a new topology to clients so that manual shutdown, change config and startup is not necessary > Others? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7552) Rolling Upgrade enhancement

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-7552: --------------------------------------- Summary: Rolling Upgrade enhancement Key: ISPN-7552 URL: https://issues.jboss.org/browse/ISPN-7552 Project: Infinispan Issue Type: Enhancement Components: Server Reporter: Gustavo Fernandes The rolling upgrade can migrate data between clusters with no downtime, but currently the procedure is somehow complicated. Some proposals to improve it: * Provide scripts to automate the procedure * Provide pre-canned configurations to start the new cluster * Server initiated cluster switch: the server would send a new topology to clients so that manual shutdown, change config and startup is not necessary Others? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2017