March 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7619) Use dynamic timeout values in the PersistenceManagerCloseableSupplier

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7619?page=com.atlassian.jira.plugin.... ] William Burns resolved ISPN-7619. --------------------------------- Fix Version/s: 9.0.0.Final Resolution: Done > Use dynamic timeout values in the PersistenceManagerCloseableSupplier > --------------------------------------------------------------------- > > Key: ISPN-7619 > URL: https://issues.jboss.org/browse/ISPN-7619 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 9.0.0.CR3 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Final > > > When dealing with stores with large number on entries the hard-coded value of 10s may not be enough -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7586) Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7586?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7586: ------------------------------------ Description: We recommend to run the target cluster with a remote-store in mode ready-only during Rolling Upgrades, and point clients from the old cluster to the new one. Clients can see the following situation: {code:java} client.put("K","value") // will get "V" back client.get("K") // Deletes will not propagate to the source cluster, // the RemoteStore is in 'read-only' mode. client.remove("K") // Returns "V". Although deleted, value will be retrieved // from the remote store cache.get("K") {code} This can break existing applications that expect a transparent and consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in non-read only mode for clients iteration but at the same time it should not allow the Rolling Upgrade itself to cause writes back to the remote store. was: Assuming a Hot Rod client pointing to the target cluster. Target cluster has a {{RemoteStore}} pointing to the source cluster in read-only mode. Clients can see the following situation: {code:java} client.put("K","value") // will get "V" back client.get("K") // Deletes will not propagate to the source cluster, // the RemoteStore is in 'read-only' mode. client.remove("K") // Returns "V". Although deleted, value will be retrieved // from the remote store cache.get("K") {code} This can break existing applications that expect a transparent and consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in non-read only mode for clients iteration but at the same time it should not allow the Rolling Upgrade itself to cause writes back to the remote store. > Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies > ---------------------------------------------------------------------------------- > > Key: ISPN-7586 > URL: https://issues.jboss.org/browse/ISPN-7586 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > > We recommend to run the target cluster with a remote-store in mode ready-only during Rolling Upgrades, and point clients from the old cluster to the new one. > Clients can see the following situation: > {code:java} > client.put("K","value") > // will get "V" back > client.get("K") > // Deletes will not propagate to the source cluster, > // the RemoteStore is in 'read-only' mode. > client.remove("K") > // Returns "V". Although deleted, value will be retrieved > // from the remote store > cache.get("K") > > {code} > This can break existing applications that expect a transparent and consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in non-read only mode for clients iteration but at the same time it should not allow the Rolling Upgrade itself to cause writes back to the remote store. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7616) Please add method like MassIndexer.reindex(Object... keys)

by Seto Kaiba (JIRA)

[ https://issues.jboss.org/browse/ISPN-7616?page=com.atlassian.jira.plugin.... ] Seto Kaiba updated ISPN-7616: ----------------------------- Summary: Please add method like MassIndexer.reindex(Object... keys) (was: Please add method like MassIndexer.reindex(Object key...)) > Please add method like MassIndexer.reindex(Object... keys) > ---------------------------------------------------------- > > Key: ISPN-7616 > URL: https://issues.jboss.org/browse/ISPN-7616 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Seto Kaiba > > Currently I can re-index by put the entry again. But it will make it replicated again in distributed cache with backups. It is necessary to provide a method to re-index the entry. > Maybe like this: > MassIndexer.reindex(Object key...) > It would be useful for relational model to re-index the parent while change the child when the parent refers to the child by key. In this situation, the parent is not modified at all. So a re-index is needed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7623) Delta write during topology change broken with triangle

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7623?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-7623: ------------------------------ Description: Applying delta write on backup requires old value to be retrieved if it's not present (e.g. when a node has just become an owner). With old replication, the entry is not committed on primary owner until backup confirms the write, and therefore the backup can retrieve the old value. With triangle, primary owner commits the value ~concurrently to sending the command to backup owner. Therefore, if backup asks for the value, it likely gets the updated value instead of the original. This would affect any command with {{LoadType.OWNER}}, but currently triangle is not implemented by functional commands which have this load type. was: Applying delta write on backup requires old value to be retrieved if it's not present (e.g. when a node has just become an owner). With old replication, the entry is not committed on primary owner until backup confirms the write, and therefore the backup can retrieve the old value. With triangle, primary owner commits the value ~concurrently to sending the command to backup owner. Therefore, if backup asks for the value, it likely gets the updated value instead of the original. > Delta write during topology change broken with triangle > ------------------------------------------------------- > > Key: ISPN-7623 > URL: https://issues.jboss.org/browse/ISPN-7623 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Radim Vansa > > Applying delta write on backup requires old value to be retrieved if it's not present (e.g. when a node has just become an owner). With old replication, the entry is not committed on primary owner until backup confirms the write, and therefore the backup can retrieve the old value. > With triangle, primary owner commits the value ~concurrently to sending the command to backup owner. Therefore, if backup asks for the value, it likely gets the updated value instead of the original. > This would affect any command with {{LoadType.OWNER}}, but currently triangle is not implemented by functional commands which have this load type. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7623) Delta write during topology change broken with triangle

by Radim Vansa (JIRA)

Radim Vansa created ISPN-7623: --------------------------------- Summary: Delta write during topology change broken with triangle Key: ISPN-7623 URL: https://issues.jboss.org/browse/ISPN-7623 Project: Infinispan Issue Type: Bug Components: Core Reporter: Radim Vansa Applying delta write on backup requires old value to be retrieved if it's not present (e.g. when a node has just become an owner). With old replication, the entry is not committed on primary owner until backup confirms the write, and therefore the backup can retrieve the old value. With triangle, primary owner commits the value ~concurrently to sending the command to backup owner. Therefore, if backup asks for the value, it likely gets the updated value instead of the original. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7590) Proper command retry handling

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7590?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-7590: ------------------------------ Summary: Proper command retry handling (was: Do not execute command twice (after retry)) > Proper command retry handling > ----------------------------- > > Key: ISPN-7590 > URL: https://issues.jboss.org/browse/ISPN-7590 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.CR2 > Reporter: Radim Vansa > Assignee: Radim Vansa > Labels: consistency > > This is an umbrella JIRA to change the way how we deal with retries after topology change. > Please link any outstanding issues that refer to incorrect return values of command during topology change. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7590) Do not execute command twice (after retry)

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7590?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-7590: ------------------------------ Summary: Do not execute command twice (after retry) (was: Log command invocations instead of value matchers) > Do not execute command twice (after retry) > ------------------------------------------ > > Key: ISPN-7590 > URL: https://issues.jboss.org/browse/ISPN-7590 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.CR2 > Reporter: Radim Vansa > Assignee: Radim Vansa > Labels: consistency > > This is an umbrella JIRA to change the way how we deal with retries after topology change. > Please link any outstanding issues that refer to incorrect return values of command during topology change. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7622) Hot Rod Rolling Upgrade throws TimeOutException

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7622?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7622: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4977 > Hot Rod Rolling Upgrade throws TimeOutException > ----------------------------------------------- > > Key: ISPN-7622 > URL: https://issues.jboss.org/browse/ISPN-7622 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > > When calling the {{synchonizeData}} operation, it timeouts after some minutes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7622) Hot Rod Rolling Upgrade throws TimeOutException

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7622?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7622: ------------------------------------ Status: Open (was: New) > Hot Rod Rolling Upgrade throws TimeOutException > ----------------------------------------------- > > Key: ISPN-7622 > URL: https://issues.jboss.org/browse/ISPN-7622 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > > When calling the {{synchonizeData}} operation, it timeouts after some minutes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7622) Hot Rod Rolling Upgrade throws TimeOutException

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-7622: --------------------------------------- Summary: Hot Rod Rolling Upgrade throws TimeOutException Key: ISPN-7622 URL: https://issues.jboss.org/browse/ISPN-7622 Project: Infinispan Issue Type: Bug Reporter: Gustavo Fernandes When calling the {{synchonizeData}} operation, it timeouts after some minutes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2017