October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3600) ignorePreviousValue should not be set on non-origin nodes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3600?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3600: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1016104|https://bugzilla.redhat.com/show_bug.cgi?id=1016104] from NEW to POST > 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-3601) REST cache store has problems with modules and finding classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3601?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3601: ----------------------------------------------- Tomas Sykora <tsykora(a)redhat.com> made a comment on [bug 1006281|https://bugzilla.redhat.com/show_bug.cgi?id=1006281] Setting target milestone to ER3, because I expect fix from William to be there already. > 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-3608) HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3608?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3608: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1017028 > HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-3608 > URL: https://issues.jboss.org/browse/ISPN-3608 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Martin Gencur > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > HotRod client's RemoteCacheManager still has a constructor that internally reads hotrod-client.properties (public RemoteCacheManager(boolean start)) and this constructor is not deprecated. > This call leads to parsing "server_list" property by ConfigurationBuilder.addServers(String servers)). > However, IPv6 addresses usually contain colons and so this parsing fails (enable to differentiate the host and port as these are separated by colon too) -- 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-3608) HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3608?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3608: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> made a comment on [bug 1017028|https://bugzilla.redhat.com/show_bug.cgi?id=1017028] See linked JIRA for more more details. > HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-3608 > URL: https://issues.jboss.org/browse/ISPN-3608 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Martin Gencur > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > HotRod client's RemoteCacheManager still has a constructor that internally reads hotrod-client.properties (public RemoteCacheManager(boolean start)) and this constructor is not deprecated. > This call leads to parsing "server_list" property by ConfigurationBuilder.addServers(String servers)). > However, IPv6 addresses usually contain colons and so this parsing fails (enable to differentiate the host and port as these are separated by colon too) -- 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-3608) HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties

by Martin Gencur (JIRA)

Martin Gencur created ISPN-3608: ----------------------------------- Summary: HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties Key: ISPN-3608 URL: https://issues.jboss.org/browse/ISPN-3608 Project: Infinispan Issue Type: Bug Affects Versions: 6.0.0.CR1 Reporter: Martin Gencur Assignee: Mircea Markus Fix For: 6.0.0.Final HotRod client's RemoteCacheManager still has a constructor that internally reads hotrod-client.properties (public RemoteCacheManager(boolean start)) and this constructor is not deprecated. This call leads to parsing "server_list" property by ConfigurationBuilder.addServers(String servers)). However, IPv6 addresses usually contain colons and so this parsing fails (enable to differentiate the host and port as these are separated by colon too) -- 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 Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3603: ----------------------------------- By the way, we probably can't just remove the remoteGetBeforeWrite command if we're on the primary owner and the key is affected by rehash - otherwise we could execute the command thinking that the key is null (or some outdated value) although it just did not made it to this node yet via ST. > 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 Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3603: ----------------------------------- Yes, there was a concurrent update which caused one replace to fail on the primary node. The entry was changed by the ReplaceCommand.perform - after the entry got wrapped, the command could be successfully execute on the node (the value was changed on primary node between the remote get and replicating the replace command there) and so it got changed in the command's context - and then it was committed. > 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-3174) String-based query language for communication between client and server

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3174?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-3174: --------------------------------------- Re-assigning to Adrian as I think he already resolved this one? > String-based query language for communication between client and server > ----------------------------------------------------------------------- > > Key: ISPN-3174 > URL: https://issues.jboss.org/browse/ISPN-3174 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Adrian Nistor > > Once the ISPN-3169 is in place, on the server, a JPAQL string that will be send on the server. > For simplicity the string will have the query params encoded in the query string itself .Compared with passing query params separately (a-la JDBC's prepared statements), this approach has reduced query caching on the server side but potentially better query planning. > For a complete remote query overview see: https://community.jboss.org/wiki/QueryingDesignInInfinispan -- 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-3174) String-based query language for communication between client and server

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3174?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3174: ---------------------------------- Assignee: Adrian Nistor (was: Mircea Markus) > String-based query language for communication between client and server > ----------------------------------------------------------------------- > > Key: ISPN-3174 > URL: https://issues.jboss.org/browse/ISPN-3174 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Adrian Nistor > > Once the ISPN-3169 is in place, on the server, a JPAQL string that will be send on the server. > For simplicity the string will have the query params encoded in the query string itself .Compared with passing query params separately (a-la JDBC's prepared statements), this approach has reduced query caching on the server side but potentially better query planning. > For a complete remote query overview see: https://community.jboss.org/wiki/QueryingDesignInInfinispan -- 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.... ] Pedro Ruivo commented on ISPN-3603: ----------------------------------- [~rvansa] can you provide me some logs? I've spoken with [~dan.berindei] and I agree that the remoteGetBeforeWrite() can be remove safely but the entry should only be committed if it is marked as changed. However, it is only marked if the command succeeds. Do you know if concurrent updates are happening at the same time (or send me the logs to look at it)? > 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013