October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3601) REST cache store has problems with modules and finding classes

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3601?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3601: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan-server/pull/173 > REST cache store has problems with modules and finding classes > -------------------------------------------------------------- > > Key: ISPN-3601 > URL: https://issues.jboss.org/browse/ISPN-3601 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0.Alpha4 > Reporter: William Burns > Assignee: William Burns > Fix For: 6.0.0.Final > > > Found in DR4 as the first release which contains Infinispan 6.0.0.Aplha4 and therefore REST Cache Store + possibility of REST Rolling Upgrades. > I've experienced problems with starting JDG node using standalone-rest-rolling-upgrade.xml example configuration (for target node). > Please see report in attachment. > You can find 2 console outputs of jdg server. The second one is after some changes in modules.xml (in rest cachestore module). > Details are shown and described in that file. -- 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 Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.... ] Work on ISPN-3603 started by Pedro Ruivo. > 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-3600) ignorePreviousValue should not be set on non-origin nodes

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3600?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3600: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2150 > ignorePreviousValue should not be set on non-origin nodes > --------------------------------------------------------- > > Key: ISPN-3600 > URL: https://issues.jboss.org/browse/ISPN-3600 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Priority: Critical > Labels: jdg62blocker > > In {{TxDistributionInterceptor.visit(Replace|Remove)Command}} the ignorePreviousValue flag is set to false on nodes which are not executing the transaction. Usually this does not matter, but when some other node requests transactions from this node (during ST), the Remove and Replace commands are sent with this flag set to false, which results in skipping their execution. > Note: the overall behaviour with ignoring the command when this flag is false and origin is not local seems to me as abusing it - the semantics of the command is far from obvious. When the non-origin node receives the exact command that is executed on the original node (without ignorePreviousValue set to true), it simply ignores it. -- 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-3607) AdvancedCache.getEntry method doesn't work with passivated entries

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3607?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3607: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2149 > AdvancedCache.getEntry method doesn't work with passivated entries > ------------------------------------------------------------------ > > Key: ISPN-3607 > URL: https://issues.jboss.org/browse/ISPN-3607 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.CR1 > Reporter: William Burns > Assignee: William Burns > Fix For: 6.0.0.Final > > > The BaseTypeConverter class assumes that when a entry is returned that the entry is an ICE. A passivated entry however is a RepeatableRead or ReadCommitted entry causing a ClassCastException. -- 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-3600) ignorePreviousValue should not be set on non-origin nodes

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3600?page=com.atlassian.jira.plugin.... ] Work on ISPN-3600 started by Pedro Ruivo. > ignorePreviousValue should not be set on non-origin nodes > --------------------------------------------------------- > > Key: ISPN-3600 > URL: https://issues.jboss.org/browse/ISPN-3600 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Priority: Critical > Labels: jdg62blocker > > In {{TxDistributionInterceptor.visit(Replace|Remove)Command}} the ignorePreviousValue flag is set to false on nodes which are not executing the transaction. Usually this does not matter, but when some other node requests transactions from this node (during ST), the Remove and Replace commands are sent with this flag set to false, which results in skipping their execution. > Note: the overall behaviour with ignoring the command when this flag is false and origin is not local seems to me as abusing it - the semantics of the command is far from obvious. When the non-origin node receives the exact command that is executed on the original node (without ignorePreviousValue set to true), it simply ignores it. -- 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-3607) AdvancedCache.getEntry method doesn't work with passivated entries

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3607?page=com.atlassian.jira.plugin.... ] Work on ISPN-3607 started by William Burns. > AdvancedCache.getEntry method doesn't work with passivated entries > ------------------------------------------------------------------ > > Key: ISPN-3607 > URL: https://issues.jboss.org/browse/ISPN-3607 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.CR1 > Reporter: William Burns > Assignee: William Burns > Fix For: 6.0.0.Final > > > The BaseTypeConverter class assumes that when a entry is returned that the entry is an ICE. A passivated entry however is a RepeatableRead or ReadCommitted entry causing a ClassCastException. -- 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-3607) AdvancedCache.getEntry method doesn't work with passivated entries

by William Burns (JIRA)

William Burns created ISPN-3607: ----------------------------------- Summary: AdvancedCache.getEntry method doesn't work with passivated entries Key: ISPN-3607 URL: https://issues.jboss.org/browse/ISPN-3607 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 6.0.0.CR1 Reporter: William Burns Assignee: William Burns Fix For: 6.0.0.Final The BaseTypeConverter class assumes that when a entry is returned that the entry is an ICE. A passivated entry however is a RepeatableRead or ReadCommitted entry causing a ClassCastException. -- 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-3600) ignorePreviousValue should not be set on non-origin nodes

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3600?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3600: -------------------------------- Assignee: Pedro Ruivo (was: Mircea Markus) > ignorePreviousValue should not be set on non-origin nodes > --------------------------------------------------------- > > Key: ISPN-3600 > URL: https://issues.jboss.org/browse/ISPN-3600 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Priority: Critical > Labels: jdg62blocker > > In {{TxDistributionInterceptor.visit(Replace|Remove)Command}} the ignorePreviousValue flag is set to false on nodes which are not executing the transaction. Usually this does not matter, but when some other node requests transactions from this node (during ST), the Remove and Replace commands are sent with this flag set to false, which results in skipping their execution. > Note: the overall behaviour with ignoring the command when this flag is false and origin is not local seems to me as abusing it - the semantics of the command is far from obvious. When the non-origin node receives the exact command that is executed on the original node (without ignorePreviousValue set to true), it simply ignores it. -- 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 updated ISPN-3603: -------------------------------- Assignee: Pedro Ruivo (was: Mircea Markus) > 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-3603) Conditional command is committed on originator when it fails on primary owner

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-3603: ------------------------------------ I think the problem is that {{EntryWrappingInterceptor}} doesn't wrap the entry on the originator, but then {{NonTxDistributionInterceptor}} retrieves the key from another owner and wraps the entry itself (because state transfer is in progress and the originator is in the process of receiving the entry via state transfer). In fact, I think {{NonTxDistributionInterceptor.remoteGetBeforeWrite()}} is not needed at all. The remote get was required in order to check the previous value (or return it, for non-conditional commands). But in non-tx caches, only the return value on the primary owner matters, and the primary owner always has the value. So it should be safe to remove {{remoteGetBeforeWrite()}} completely. > 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: Mircea Markus > 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013