November 2014 - infinispan-issues

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

by Matej Čimbora (JIRA)

Matej Čimbora created ISPN-4975: ----------------------------------- Summary: 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 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)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4974) Cross site state transfer - CLI ops throw NPE when backup is not defined

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4974?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4974: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1163332 > Cross site state transfer - CLI ops throw NPE when backup is not defined > ------------------------------------------------------------------------ > > Key: ISPN-4974 > URL: https://issues.jboss.org/browse/ISPN-4974 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 7.0.0.Final > Reporter: Matej Čimbora > Assignee: Pedro Ruivo > > When <backups><backup site="XYZ"/></backups> is not present in configuration of given cache, "site" CLI operations are still available on the node. However, their usage leads to NPEs being thrown, e.g. > [31m22:40:13,381 ERROR [org.infinispan.cli.interpreter.Interpreter] (management-handler-thread - 4) ISPN019003: Interpreter error: java.lang.NullPointerException > at org.infinispan.cli.interpreter.statement.SiteStatement.execute(SiteStatement.java:46) [infinispan-cli-interpreter-7.0.0.Final.jar:7.0.0.Final] > at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:149) [infinispan-cli-interpreter-7.0.0.Final.jar:7.0.0.Final] > at org.infinispan.server.infinispan.SecurityActions$6.run(SecurityActions.java:255) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final] > at org.infinispan.server.infinispan.SecurityActions$6.run(SecurityActions.java:252) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final] > at org.infinispan.security.Security.doPrivileged(Security.java:89) [infinispan-core-7.0.0.Final.jar:7.0.0.Final] > at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:68) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final] > at org.infinispan.server.infinispan.SecurityActions.executeInterpreter(SecurityActions.java:258) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final] > at org.jboss.as.clustering.infinispan.subsystem.CliInterpreterHandler.execute(CliInterpreterHandler.java:49) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:606) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:484) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:281) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:276) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:271) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:145) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60] > at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_60] > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4974) Cross site state transfer - CLI ops throw NPE when backup is not defined

by Matej Čimbora (JIRA)

Matej Čimbora created ISPN-4974: ----------------------------------- Summary: Cross site state transfer - CLI ops throw NPE when backup is not defined Key: ISPN-4974 URL: https://issues.jboss.org/browse/ISPN-4974 Project: Infinispan Issue Type: Bug Components: CLI Affects Versions: 7.0.0.Final Reporter: Matej Čimbora Assignee: Pedro Ruivo When <backups><backup site="XYZ"/></backups> is not present in configuration of given cache, "site" CLI operations are still available on the node. However, their usage leads to NPEs being thrown, e.g. [31m22:40:13,381 ERROR [org.infinispan.cli.interpreter.Interpreter] (management-handler-thread - 4) ISPN019003: Interpreter error: java.lang.NullPointerException at org.infinispan.cli.interpreter.statement.SiteStatement.execute(SiteStatement.java:46) [infinispan-cli-interpreter-7.0.0.Final.jar:7.0.0.Final] at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:149) [infinispan-cli-interpreter-7.0.0.Final.jar:7.0.0.Final] at org.infinispan.server.infinispan.SecurityActions$6.run(SecurityActions.java:255) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final] at org.infinispan.server.infinispan.SecurityActions$6.run(SecurityActions.java:252) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final] at org.infinispan.security.Security.doPrivileged(Security.java:89) [infinispan-core-7.0.0.Final.jar:7.0.0.Final] at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:68) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final] at org.infinispan.server.infinispan.SecurityActions.executeInterpreter(SecurityActions.java:258) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final] at org.jboss.as.clustering.infinispan.subsystem.CliInterpreterHandler.execute(CliInterpreterHandler.java:49) [infinispan-server-infinispan-7.0.0.Final.jar:7.0.0.Final] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:606) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:484) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:281) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:276) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:271) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:145) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60] at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_60] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.Final.jar:8.1.0.Final] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4842) Reduce the overhead of clustered caches

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4842?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4842: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1163616 > Reduce the overhead of clustered caches > --------------------------------------- > > Key: ISPN-4842 > URL: https://issues.jboss.org/browse/ISPN-4842 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 7.0.0.CR1 > Reporter: Takayoshi Kimura > > A user is testing 500 nodes cluster with 500 dist caches defined, and plans to expand it to 3000 caches. > Infinispan manages consistent hash per cache, uses a JGroups channel per cache and uses several threads per cache. It gives significant overhead with this large size cluster. When tested with this size, Infinispan easily exhausted all threads in the thread pools and deadlocks, and requires several thousands threads to handle massive JOIN requests - the coord receives 499 * 3000 JOIN requests. > It would be great if we can share the consistent hash and resources between caches. For example, define a "master" dist cache and allow other caches to refer to the master cache for resource sharing. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4891) ExpiryTest failures caused by ISPN-4836

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4891?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4891: ------------------------------------------ Bugzilla Update: (was: Perform) Bugzilla References: (was: https://bugzilla.redhat.com/show_bug.cgi?id=1160416) > ExpiryTest failures caused by ISPN-4836 > --------------------------------------- > > Key: ISPN-4891 > URL: https://issues.jboss.org/browse/ISPN-4891 > Project: Infinispan > Issue Type: Bug > Reporter: Pedro Ruivo > Assignee: William Burns > Fix For: 7.0.0.Final > > > The following tests are failing: > {code} > ExpiryTest.testEntrySetAfterExpiryInPut:233->doTestEntrySetAfterExpiryInPut:283 expected:<[1=v1-testEntrySetAfterExpiryInPut, 2=v2-testEntrySetAfterExpiryInPut]> but was:<[]> > ExpiryTest.testKeySetAfterExpiryInTransaction:370->doKeySetAfterExpiryInTransaction:402 expected:<[1, 2, 3]> but was:<[3]> > {code} > A possible solution (by Dan) would be to copy to make sure the entries don't disappear from the set. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2133) Provide a context for object de-serialization

by Emmanuel Bernard (JIRA)

[ https://issues.jboss.org/browse/ISPN-2133?page=com.atlassian.jira.plugin.... ] Emmanuel Bernard commented on ISPN-2133: ---------------------------------------- It kinda depends on the scope of the context. If that's per Infinispan operation, I think it would be really hard to do (esp with the async stuff). If that's per cache. I guess when you create a cache you could have some fluent API of sort to attach some context that would be provided to the externalizer. Or better and more simply, offer a way to attach externalizers just for a specific cache. In which case we could add state to them via their constructor. > Provide a context for object de-serialization > --------------------------------------------- > > Key: ISPN-2133 > URL: https://issues.jboss.org/browse/ISPN-2133 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Sanne Grinovero > Labels: SLOWING_OGM > > See proposal description at > http://lists.jboss.org/pipermail/infinispan-dev/2012-June/010925.html -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1239) Graceful shutdown should be supported

by Alan Field (JIRA)

[ https://issues.jboss.org/browse/ISPN-1239?page=com.atlassian.jira.plugin.... ] Alan Field commented on ISPN-1239: ---------------------------------- The issues involved with shared cachestores and preloading after restarting the cluster are also discussed in this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1122662 > Graceful shutdown should be supported > ------------------------------------- > > Key: ISPN-1239 > URL: https://issues.jboss.org/browse/ISPN-1239 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.0.0.FINAL > Reporter: Manik Surtani > Priority: Critical > Labels: clean_shutdown, rehashing > > Currently, killing any node will result in a rehash. A mechanism for clean shutdown should also be supported, so that a rehash is *not* triggered. Useful when the entire cluster is being intentionally brought down. > Need to think about how we do this; perhaps a LEAVE message that will prevent nodes triggering a rehash when a subsequent view change is detected. This could be done programmatically via a {{clean}} parameter to {{stop()}}, but we should explore alternatives here. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1239) Graceful shutdown should be supported

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-1239?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-1239: --------------------------------------- We also need to consider the impact when the cache is persisted (ref https://issues.jboss.org/browse/ISPN-4908 ) > Graceful shutdown should be supported > ------------------------------------- > > Key: ISPN-1239 > URL: https://issues.jboss.org/browse/ISPN-1239 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.0.0.FINAL > Reporter: Manik Surtani > Priority: Critical > Labels: clean_shutdown, rehashing > > Currently, killing any node will result in a rehash. A mechanism for clean shutdown should also be supported, so that a rehash is *not* triggered. Useful when the entire cluster is being intentionally brought down. > Need to think about how we do this; perhaps a LEAVE message that will prevent nodes triggering a rehash when a subsequent view change is detected. This could be done programmatically via a {{clean}} parameter to {{stop()}}, but we should explore alternatives here. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2133) Provide a context for object de-serialization

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2133?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-2133: ------------------------------------ [~sannegrinovero] the initial description didn't say anything about having a different context for each cache :) [~sannegrinovero] [~epbernard] any suggestions on how the API should look? > Provide a context for object de-serialization > --------------------------------------------- > > Key: ISPN-2133 > URL: https://issues.jboss.org/browse/ISPN-2133 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Sanne Grinovero > Labels: SLOWING_OGM > > See proposal description at > http://lists.jboss.org/pipermail/infinispan-dev/2012-June/010925.html -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4811) Add Cross-Site state transfer operations and metrics to CLI

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4811?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4811: ----------------------------------------------- Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1158845|https://bugzilla.redhat.com/show_bug.cgi?id=1158845] from ON_QA to VERIFIED > Add Cross-Site state transfer operations and metrics to CLI > ----------------------------------------------------------- > > Key: ISPN-4811 > URL: https://issues.jboss.org/browse/ISPN-4811 > Project: Infinispan > Issue Type: Sub-task > Components: Cross-Site Replication > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Final > > > Add the operations to control the cross-site state transfer and the metrics to check the state of running state transfer to CLI. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2014