November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-3336) Extended Statistics check list

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3336?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3336: ------------------------------- Priority: Major (was: Critical) > Extended Statistics check list > ------------------------------ > > Key: ISPN-3336 > URL: https://issues.jboss.org/browse/ISPN-3336 > Project: Infinispan > Issue Type: Task > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: core > Fix For: 7.1.0.Alpha1 > > > * add documentation > * check for duplicate stats; > * check for not exposed statistics > * try to improve the code (reduce the number of access to the CHM) > * add tests to check if they are exported via JMX correctly > * failing test: OptimisticLockingTxClusterExtendedStatisticLogicTest.testWriteSkewOnNonOwner > * failing test: PessimisticLockingTxClusterExtendedStatisticLogicTest.testDeadlockOnNonOwnerWithRemoteTx -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5020) Create OSGi blueprint file for SoftIndexFileStore

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-5020?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-5020: -------------------------------- Status: Open (was: New) > Create OSGi blueprint file for SoftIndexFileStore > ------------------------------------------------- > > Key: ISPN-5020 > URL: https://issues.jboss.org/browse/ISPN-5020 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Loaders and Stores > Reporter: Martin Gencur > Assignee: Martin Gencur > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5020) Create OSGi blueprint file for SoftIndexFileStore

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-5020?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-5020: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3106 > Create OSGi blueprint file for SoftIndexFileStore > ------------------------------------------------- > > Key: ISPN-5020 > URL: https://issues.jboss.org/browse/ISPN-5020 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Loaders and Stores > Reporter: Martin Gencur > Assignee: Martin Gencur > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5020) Create OSGi blueprint file for SoftIndexFileStore

by Martin Gencur (JIRA)

Martin Gencur created ISPN-5020: ----------------------------------- Summary: Create OSGi blueprint file for SoftIndexFileStore Key: ISPN-5020 URL: https://issues.jboss.org/browse/ISPN-5020 Project: Infinispan Issue Type: Enhancement Components: Configuration, Loaders and Stores Reporter: Martin Gencur Assignee: Martin Gencur -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4969) Stopping a cache will stop all KeyAffinityServices created for other caches in the cache manager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4969?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4969: ----------------------------------------------- Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1163820|https://bugzilla.redhat.com/show_bug.cgi?id=1163820] from ON_QA to VERIFIED > Stopping a cache will stop all KeyAffinityServices created for other caches in the cache manager > ------------------------------------------------------------------------------------------------ > > Key: ISPN-4969 > URL: https://issues.jboss.org/browse/ISPN-4969 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.8.Final, 6.0.2.Final, 7.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Fix For: 7.0.1.Final, 5.2.9.Final, 6.0.3.Final > > > We've had several reports in the WildFly forums of application runtime failures following undeployment of a separate application. > WF creates a cache instance for each web application within the same cache container. However, KeyAffinityServiceImpl registers a cache manager listener that calls stop() on a @CacheStoppedEvent. However, this event might be triggered by any cache, not necessarily the cache with to which the KeyAffinityService is associated. > The KeyAffinityServiceImpl.handleCacheStopped(CacheStoppedEvent) should only call stop() if the event.getCacheName() equals the name of the cache to which the affinity service is associated. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4975) Cross site state transfer - status of push gets stuck at "SENDING" after being cancelled

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4975?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4975: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Cross site state transfer - status of push gets stuck at "SENDING" after being cancelled > ---------------------------------------------------------------------------------------- > > Key: ISPN-4975 > URL: https://issues.jboss.org/browse/ISPN-4975 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 7.0.0.Final > Reporter: Matej Čimbora > Assignee: Pedro Ruivo > Fix For: 7.1.0.Alpha1 > > > After invoking: site --cancelpush backupSite on the producer site, status of the push operation seems to get stuck at "SENDING" value (tested by site --pushstatus), even if state transfer is not currently in progress. > Invoking site --cancelreceive mainSite on the consumer site works correctly. New invocation of site --push backupsite leads to "X-Site state transfer to '%s' already started!" being displayed. The issue seems to be caused by XSiteStateTransferManagerImpl.siteCollector not being cleared. > Used configuration: > distributed caches, site A: 2 nodes, site B: 3 nodes, B is a backup for A. > Scenario > - Start A,B > - Take B offline using takeSiteOffline > - Load data into A > - Push state into B > - CancelPushState B > -- PushStateStatus remains stuck at SENDING & new push is not possible -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5019: ------------------------------- Status: Open (was: New) > After coordinator change, cache topologies should be installed in parallel > -------------------------------------------------------------------------- > > Key: ISPN-5019 > URL: https://issues.jboss.org/browse/ISPN-5019 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Alpha1 > > > When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches. > We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-5019: ---------------------------------- Assignee: Dan Berindei > After coordinator change, cache topologies should be installed in parallel > -------------------------------------------------------------------------- > > Key: ISPN-5019 > URL: https://issues.jboss.org/browse/ISPN-5019 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Alpha1 > > > When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches. > We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5019: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1163573 > After coordinator change, cache topologies should be installed in parallel > -------------------------------------------------------------------------- > > Key: ISPN-5019 > URL: https://issues.jboss.org/browse/ISPN-5019 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Alpha1 > > > When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches. > We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5019: ---------------------------------- Summary: After coordinator change, cache topologies should be installed in parallel Key: ISPN-5019 URL: https://issues.jboss.org/browse/ISPN-5019 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 7.0.2.Final Reporter: Dan Berindei Priority: Critical Fix For: 7.1.0.Alpha1 When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches. We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2014