October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3443) WriteCommand may be ignored during state transfer

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3443?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3443: ----------------------------------- You're right - should I rename this JIRA back to RemoveCommand may be ignored during state transfer and create different JIRA for overwriting by ST? > WriteCommand may be ignored during state transfer > ------------------------------------------------- > > Key: ISPN-3443 > URL: https://issues.jboss.org/browse/ISPN-3443 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency, State transfer > Affects Versions: 6.0.0.Alpha3 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Blocker > Labels: jdg62blocker > Fix For: 6.0.0.CR1 > > > Distributed sync non-tx cache. > Situation: > 1) A node is joining the cluster, requesting some segment > 2) RemoveCommand is sent to backup owner with ignorePreviousValue=true > 3) It looks up the entry and finds null > 4) State transfer invokes the PutKeyValueCommand and sets the value for removed entry (updateKeys has not the key yet) > 5) RemoveCommand adds its key to updateKeys set, but it does not remove the value as it is already null (in its context) > Result: the value is removed on primary but on backup this is still present -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3443) WriteCommand may be ignored during state transfer

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3443?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-3443: ------------------------------------ Radim, I missed your comment about the race condition in EntryWrappingInterceptor.commitEntryIfNeeded. I don't think it's a case of the WriteCommand being ignored, though: the command is committed, it's just that state transfer than overwrites the value. > WriteCommand may be ignored during state transfer > ------------------------------------------------- > > Key: ISPN-3443 > URL: https://issues.jboss.org/browse/ISPN-3443 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency, State transfer > Affects Versions: 6.0.0.Alpha3 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Blocker > Labels: jdg62blocker > Fix For: 6.0.0.CR1 > > > Distributed sync non-tx cache. > Situation: > 1) A node is joining the cluster, requesting some segment > 2) RemoveCommand is sent to backup owner with ignorePreviousValue=true > 3) It looks up the entry and finds null > 4) State transfer invokes the PutKeyValueCommand and sets the value for removed entry (updateKeys has not the key yet) > 5) RemoveCommand adds its key to updateKeys set, but it does not remove the value as it is already null (in its context) > Result: the value is removed on primary but on backup this is still present -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3443) WriteCommand may be ignored during state transfer

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3443?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3443: ------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/2117, https://github.com/infinispan/infinispan/pull/2151 (was: https://github.com/infinispan/infinispan/pull/2117) > WriteCommand may be ignored during state transfer > ------------------------------------------------- > > Key: ISPN-3443 > URL: https://issues.jboss.org/browse/ISPN-3443 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency, State transfer > Affects Versions: 6.0.0.Alpha3 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Blocker > Labels: jdg62blocker > Fix For: 6.0.0.CR1 > > > Distributed sync non-tx cache. > Situation: > 1) A node is joining the cluster, requesting some segment > 2) RemoveCommand is sent to backup owner with ignorePreviousValue=true > 3) It looks up the entry and finds null > 4) State transfer invokes the PutKeyValueCommand and sets the value for removed entry (updateKeys has not the key yet) > 5) RemoveCommand adds its key to updateKeys set, but it does not remove the value as it is already null (in its context) > Result: the value is removed on primary but on backup this is still present -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3603) Conditional command is committed on originator when it fails on primary owner

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3603: ------------------------------------- [~rvansa] this doesn't look like something introduced in 6.0.0 but something existing since 5.2.x, can you please confirm? > Conditional command is committed on originator when it fails on primary owner > ----------------------------------------------------------------------------- > > Key: ISPN-3603 > URL: https://issues.jboss.org/browse/ISPN-3603 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Priority: Critical > Labels: jdg62blocker > > In non-tx cache, when conditional command (e.g. ReplaceCommand) fails on primary owner because the old value is not equal to current value, the NonTxDistributionInterceptor.visitReplaceCommand returns false but the entry is committed in EntryWrappingInterceptor anyway. > Speaking about EntryWrappingInterceptor.invokeNextAndApplyChanges: NonTxDistributionInterceptor does not mark the command as unsuccessful if it fails on the primary owner, therefore, checking for command.isSuccessful() in order to retry the command upon topology change may seem insufficient. -- 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, 6 months

1
0
0 / 0

[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: ----------------------------------------------- Anna Manukyan <amanukya(a)redhat.com> changed the Status of [bug 974402|https://bugzilla.redhat.com/show_bug.cgi?id=974402] from ON_QA to VERIFIED > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3570) Server state transfer ignores awaitInitialStateTransfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3570?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3570: ----------------------------------------------- Anna Manukyan <amanukya(a)redhat.com> made a comment on [bug 974402|https://bugzilla.redhat.com/show_bug.cgi?id=974402] Verified! Thanks a lot. > Server state transfer ignores awaitInitialStateTransfer > ------------------------------------------------------- > > Key: ISPN-3570 > URL: https://issues.jboss.org/browse/ISPN-3570 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.CR1 > > -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3570) Server state transfer ignores awaitInitialStateTransfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3570?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3570: ----------------------------------------------- Anna Manukyan <amanukya(a)redhat.com> changed the Status of [bug 974402|https://bugzilla.redhat.com/show_bug.cgi?id=974402] from ON_QA to VERIFIED > Server state transfer ignores awaitInitialStateTransfer > ------------------------------------------------------- > > Key: ISPN-3570 > URL: https://issues.jboss.org/browse/ISPN-3570 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.CR1 > > -- 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, 6 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: ----------------------------------------------- Anna Manukyan <amanukya(a)redhat.com> changed the Status of [bug 974402|https://bugzilla.redhat.com/show_bug.cgi?id=974402] from ON_QA to VERIFIED > 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: NadirX > 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, 6 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: ----------------------------------------------- Anna Manukyan <amanukya(a)redhat.com> made a comment on [bug 974402|https://bugzilla.redhat.com/show_bug.cgi?id=974402] Verified! Thanks a lot. > 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: NadirX > 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, 6 months

1
0
0 / 0

[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: ----------------------------------------------- Anna Manukyan <amanukya(a)redhat.com> made a comment on [bug 974402|https://bugzilla.redhat.com/show_bug.cgi?id=974402] Verified! Thanks a lot. > 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, 6 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 October 2013