August 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3140) JMX operation to suppress state transfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3140?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3140: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 974402|https://bugzilla.redhat.com/show_bug.cgi?id=974402] from ASSIGNED to MODIFIED > JMX operation to suppress state transfer > ---------------------------------------- > > Key: ISPN-3140 > URL: https://issues.jboss.org/browse/ISPN-3140 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache, State transfer > Affects Versions: 5.2.6.Final > Reporter: Manik Surtani > Assignee: Dan Berindei > Fix For: 5.2.7.Final, 5.3.0.CR2, 5.3.0.Final > > > This feature request is to expose a JMX operation on each node, to suppress state transfer for a period of time. This flag would be {{false}} by default. > The use case of this flag would be to ease bringing down (and up) a cluster for maintenance work. A typical workflow would be: > 1) Shut down application requests to the data grid > 2) Suppress state transfer on all nodes via JMX > 3) Bring down all nodes > 4) Perform maintenance work > 5) Bring up nodes, one at a time. As each node comes up, disable state transfer for the node via JMX. > 6) Once all nodes are up, enable state transfer for each node again via JMX > 7) Allow application requests to reach the grid again. > The purpose of this is to allow smooth and fast shutdown and startup, remove the risk of OOM errors (when bringing a grid down). > This is a small but useful subset of full manual state transfer as defined in ISPN-1394. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3373) HotRod topology cache should allow disabling awaitInitialTransfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3373?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3373: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 974402|https://bugzilla.redhat.com/show_bug.cgi?id=974402] from ASSIGNED to MODIFIED > HotRod topology cache should allow disabling awaitInitialTransfer > ----------------------------------------------------------------- > > Key: ISPN-3373 > URL: https://issues.jboss.org/browse/ISPN-3373 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols, Server > Affects Versions: 6.0.0.Alpha1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.Alpha2 > > > When a server with a hotrod endpoint joins a cluster where state transfer has been disabled (ISPN-3140), waiting for initial state transfer should also be disabled on the topology cache, otherwise failures occur. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3357) Insufficient owners with putIfAbsent during rebalance

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3357?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3357: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 989808|https://bugzilla.redhat.com/show_bug.cgi?id=989808] from ASSIGNED to MODIFIED > Insufficient owners with putIfAbsent during rebalance > ----------------------------------------------------- > > Key: ISPN-3357 > URL: https://issues.jboss.org/browse/ISPN-3357 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.4.Final, 6.0.0.Alpha1 > Reporter: Takayoshi Kimura > Assignee: Dan Berindei > Priority: Critical > Fix For: 5.2.8.Final, 6.0.0.Alpha3 > > Attachments: 7c29bccb.log, ISPN-3357-full-logs-leave.zip > > > Here is test scenario: > * DIST numOwners=2, start with 3 nodes cluster then join 1 node during load > * HotRod putIfAbsent accesses from 40 threads (1 process, 1 remote cache instance), 40000 entries total > After the test run, the numberOfEntries on each node are: > * node1: 20074 > * node2: 19888 > * node3: 20114 > * node4: 18885 > Total is 78961, 1039 entries are missing. No error on HotRod client side so 80000 entries should be there. > Let's take a look at example missing entry, hash(thread01key151) = 7c29bccb. > Current CH: owners(7c29bccb) are [node1, node2] > Pending CH: owners(7c29bccb) are [node1, node2, node4] > Balanced CH: owners(7c29bccb) are [node1, node4] > The events sequence is: > * hotrod -> node1 > * node1 -> node2, node4 > * node2 committed entry > * node4 performed clustered get before write, got a value from node2 and will not commit the entry because this node thinks it's not changed/created > * node1 committed entry > * node2 invalidates the entry because it's no longer an owner > Result owners(7c29bccb) are only node1 and node4 is missing. This entry may be completely lost by further rebalances when node4 is donor for this segment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2903: ----------------------------------------------- Scott Mumford <smumford(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] Setting for exclusion from 6.1.1 Release notes and removing NEEDINFO request. > Manual eviction should not delete entry from cache store > -------------------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: 5.2.x, jdg6 > Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. > It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3434) DistTotalOrderL1WriteSkewTest test doesn't run with L1 enabled

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3434?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3434: ------------------------------ Assignee: Pedro Ruivo (was: Mircea Markus) > DistTotalOrderL1WriteSkewTest test doesn't run with L1 enabled > -------------------------------------------------------------- > > Key: ISPN-3434 > URL: https://issues.jboss.org/browse/ISPN-3434 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Reporter: William Burns > Assignee: Pedro Ruivo > > The decorate method doesn't invoke the super method, which causes the L1 to not be enabled. By invoking the super method and enabling L1, there are actually failing tests. > Failed tests: > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueNonExistingKey:73->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeAY-38834. expected:<v1> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueNonExistingKeyOnNonOwner:77->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBC-51791. expected:<v1> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueOnNonExistingKey:65->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBF-6894. expected:<v1> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueOnNonExistingKeyOnNonOwner:69->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBK-23011. expected:<v1> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueNonExistingKey:89->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBO-8015. expected:<null> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueNonExistingKeyOnNonOwner:93->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBS-18673. expected:<null> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueOnNonExistingKey:81->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBV-26641. expected:<null> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueOnNonExistingKeyOnNonOwner:85->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeCA-47053. expected:<null> but was:<v2> > DistTotalOrderL1WriteSkewTest>DistWriteSkewTest.testNullEntries:185 null > DistTotalOrderL1WriteSkewTest>DistWriteSkewTest.testWriteSkew:48 null > DistTotalOrderL1WriteSkewTest>DistWriteSkewTest.testWriteSkewMultiEntries:146 null -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3434) DistTotalOrderL1WriteSkewTest test doesn't run with L1 enabled

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3434?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3434: -------------------------------- Issue Type: Bug (was: Feature Request) > DistTotalOrderL1WriteSkewTest test doesn't run with L1 enabled > -------------------------------------------------------------- > > Key: ISPN-3434 > URL: https://issues.jboss.org/browse/ISPN-3434 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Reporter: William Burns > Assignee: Mircea Markus > > The decorate method doesn't invoke the super method, which causes the L1 to not be enabled. By invoking the super method and enabling L1, there are actually failing tests. > Failed tests: > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueNonExistingKey:73->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeAY-38834. expected:<v1> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueNonExistingKeyOnNonOwner:77->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBC-51791. expected:<v1> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueOnNonExistingKey:65->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBF-6894. expected:<v1> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueOnNonExistingKeyOnNonOwner:69->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBK-23011. expected:<v1> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueNonExistingKey:89->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBO-8015. expected:<null> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueNonExistingKeyOnNonOwner:93->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBS-18673. expected:<null> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueOnNonExistingKey:81->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBV-26641. expected:<null> but was:<v2> > DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueOnNonExistingKeyOnNonOwner:85->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeCA-47053. expected:<null> but was:<v2> > DistTotalOrderL1WriteSkewTest>DistWriteSkewTest.testNullEntries:185 null > DistTotalOrderL1WriteSkewTest>DistWriteSkewTest.testWriteSkew:48 null > DistTotalOrderL1WriteSkewTest>DistWriteSkewTest.testWriteSkewMultiEntries:146 null -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3433) Versioned L1 values don't expire

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3433?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3433: -------------------------------- Issue Type: Bug (was: Feature Request) > Versioned L1 values don't expire > -------------------------------- > > Key: ISPN-3433 > URL: https://issues.jboss.org/browse/ISPN-3433 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: William Burns > Assignee: William Burns > > When versioned entries are enabled it doesn't properly apply the lifespan value to L1 entries causing them to never expire. > This requires a change in the ClusterDependentLogic class to apply the L1 lifespan to the passed in metadata as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3434) DistTotalOrderL1WriteSkewTest test doesn't run with L1 enabled

by William Burns (JIRA)

William Burns created ISPN-3434: ----------------------------------- Summary: DistTotalOrderL1WriteSkewTest test doesn't run with L1 enabled Key: ISPN-3434 URL: https://issues.jboss.org/browse/ISPN-3434 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Reporter: William Burns Assignee: Mircea Markus The decorate method doesn't invoke the super method, which causes the L1 to not be enabled. By invoking the super method and enabling L1, there are actually failing tests. Failed tests: DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueNonExistingKey:73->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeAY-38834. expected:<v1> but was:<v2> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueNonExistingKeyOnNonOwner:77->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBC-51791. expected:<v1> but was:<v2> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueOnNonExistingKey:65->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBF-6894. expected:<v1> but was:<v2> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testPutIgnoreReturnValueOnNonExistingKeyOnNonOwner:69->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBK-23011. expected:<v1> but was:<v2> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueNonExistingKey:89->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBO-8015. expected:<null> but was:<v2> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueNonExistingKeyOnNonOwner:93->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBS-18673. expected:<null> but was:<v2> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueOnNonExistingKey:81->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeBV-26641. expected:<null> but was:<v2> DistTotalOrderL1WriteSkewTest>AbstractClusteredWriteSkewTest.testRemoveIgnoreReturnValueOnNonExistingKeyOnNonOwner:85->AbstractClusteredWriteSkewTest.doIgnoreReturnValueTest:241 wrong final value for DistTotalOrderL1WriteSkewTest-NodeCA-47053. expected:<null> but was:<v2> DistTotalOrderL1WriteSkewTest>DistWriteSkewTest.testNullEntries:185 null DistTotalOrderL1WriteSkewTest>DistWriteSkewTest.testWriteSkew:48 null DistTotalOrderL1WriteSkewTest>DistWriteSkewTest.testWriteSkewMultiEntries:146 null -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3433) Versioned L1 values don't expire

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3433?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-3433: ----------------------------------- Assignee: William Burns (was: Mircea Markus) > Versioned L1 values don't expire > -------------------------------- > > Key: ISPN-3433 > URL: https://issues.jboss.org/browse/ISPN-3433 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: William Burns > Assignee: William Burns > > When versioned entries are enabled it doesn't properly apply the lifespan value to L1 entries causing them to never expire. > This requires a change in the ClusterDependentLogic class to apply the L1 lifespan to the passed in metadata as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3433) Versioned L1 values don't expire

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3433?page=com.atlassian.jira.plugin.... ] Work on ISPN-3433 started by William Burns. > Versioned L1 values don't expire > -------------------------------- > > Key: ISPN-3433 > URL: https://issues.jboss.org/browse/ISPN-3433 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: William Burns > Assignee: William Burns > > When versioned entries are enabled it doesn't properly apply the lifespan value to L1 entries causing them to never expire. > This requires a change in the ClusterDependentLogic class to apply the L1 lifespan to the passed in metadata as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 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 August 2013