January 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10784) Docs: Clarifying sync vs async behaviour

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-10784?page=com.atlassian.jira.plugi... ] Donald Naro closed ISPN-10784. ------------------------------ > Docs: Clarifying sync vs async behaviour > ---------------------------------------- > > Key: ISPN-10784 > URL: https://issues.redhat.com/browse/ISPN-10784 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > Fix For: 9.1.8.Final > > > Expand xsite docs on ASYNC SYNC settings, client, intra-cluster and xsite. > SYNC ensure the call is complete or not > whereas ASYNC might cause inconsistency if there is a failure - and the user get only a log WARN message (or nothing) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10729) Server Docs: Single Port and Auto HotRod Selection

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-10729?page=com.atlassian.jira.plugi... ] Donald Naro closed ISPN-10729. ------------------------------ > Server Docs: Single Port and Auto HotRod Selection > -------------------------------------------------- > > Key: ISPN-10729 > URL: https://issues.redhat.com/browse/ISPN-10729 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > Fix For: 10.1.0.Final > > > Productize server docs, chapter 7. Single Port -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11144) Cluster Max Idle can miss a touch during state transfer

by Will Burns (Jira)

Will Burns created ISPN-11144: --------------------------------- Summary: Cluster Max Idle can miss a touch during state transfer Key: ISPN-11144 URL: https://issues.redhat.com/browse/ISPN-11144 Project: Infinispan Issue Type: Bug Components: Expiration Reporter: Will Burns The new max idle in ISPN-11020 can have an issue that when a touch command is being replicated to a write owner that isn't a read owner that the touch is missed. This can occur if a state provider node sends the entry without the touched timestamp to the new owner, but the touch command is received on the new owner before the entry is written on the new owner. This should be a pretty small edge case, but we should close it at some point. The reason it is small is that it requires a touch command to be done at the same time as state transfer but before the state provider node but before the value is written. Then for the issue to manifest there must be a read on this new owner after the old expiration time but before the new one, without any other reads on any owners. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11144) Cluster Max Idle can miss a touch during state transfer

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11144?page=com.atlassian.jira.plugi... ] Will Burns commented on ISPN-11144: ----------------------------------- This should be fixable by implementing a `CommitManager#touch` method that stores the access time until the value is written. > Cluster Max Idle can miss a touch during state transfer > ------------------------------------------------------- > > Key: ISPN-11144 > URL: https://issues.redhat.com/browse/ISPN-11144 > Project: Infinispan > Issue Type: Bug > Components: Expiration > Reporter: Will Burns > Priority: Major > > The new max idle in ISPN-11020 can have an issue that when a touch command is being replicated to a write owner that isn't a read owner that the touch is missed. This can occur if a state provider node sends the entry without the touched timestamp to the new owner, but the touch command is received on the new owner before the entry is written on the new owner. > This should be a pretty small edge case, but we should close it at some point. The reason it is small is that it requires a touch command to be done at the same time as state transfer but before the state provider node but before the value is written. Then for the issue to manifest there must be a read on this new owner after the old expiration time but before the new one, without any other reads on any owners. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11129) High Availability for non-shared indexes on DIST caches

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11129?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11129: ------------------------------------- Description: 'Non-shared indexes' is a setup when each node has a local index backed by the file system, using either the near-real-time or the FS index managers. For REPL caches, a full copy of the index is kept in each node. As long as at least on node is up the queries hit the local index which represents the full index of the data. But non-shared indexes has some drawbacks for DIST caches: each node only indexes data that the node is the primary owner. If a node goes down, there is no redundancy. This issue aims to solve this issue at two levels: * Indexing: replicated entries should be indexed for redundancy purposes. If a primary owner goes down, the entry is indexed in the backup owner. This should follow exactly the data distribution on the cache in terms of number of replicas and rebalancing * Querying: query broadcast is currently used for non-shared indexes. If replicated entries start to be indexed, a mechanism will have to be used to avoid retuning repeated results, since currently the broadcast simply queries all the entries in each node and join the result. was: 'Non-shared indexes' is a setup when each node has a local index backed by the file system, using either the near-real-time or the FS index managers. For REPL caches, a full copy of the index is kept in each node. As long as at least on node is up the queries hit the local index which represents the full index of the data. But non-shared indexes has some drawbacks for DIST caches: each node only indexes data that the node is the primary owner. If a node goes down, there is no redundancy. This issue aims to solve this issue at two levels: * Indexing: replicated entries should be indexed for redundancy purposes. If a primary owner goes down, the entry is indexed in the backup owner. This should follow exactly the data distribution on the cache in terms of number of replicas and rebalancing * Querying: query broadcast is currently used for non-shared indexes. If replicated entires start to be indexed, a mechanism will have to be used to avoid retuning repeated results, since currently the broadcast simply queries all the entries in each node and join the result. > High Availability for non-shared indexes on DIST caches > ------------------------------------------------------- > > Key: ISPN-11129 > URL: https://issues.redhat.com/browse/ISPN-11129 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > > 'Non-shared indexes' is a setup when each node has a local index backed by the file system, using either the near-real-time or the FS index managers. > For REPL caches, a full copy of the index is kept in each node. As long as at least on node is up the queries hit the local index which represents the full index of the data. > But non-shared indexes has some drawbacks for DIST caches: each node only indexes data that the node is the primary owner. If a node goes down, there is no redundancy. This issue aims to solve this issue at two levels: > * Indexing: replicated entries should be indexed for redundancy purposes. If a primary owner goes down, the entry is indexed in the backup owner. This should follow exactly the data distribution on the cache in terms of number of replicas and rebalancing > * Querying: query broadcast is currently used for non-shared indexes. If replicated entries start to be indexed, a mechanism will have to be used to avoid retuning repeated results, since currently the broadcast simply queries all the entries in each node and join the result. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10835) XSite Docs: Productization Effort

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-10835?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-10835: ------------------------------- Sprint: DataGrid Sprint #38 > XSite Docs: Productization Effort > --------------------------------- > > Key: ISPN-10835 > URL: https://issues.redhat.com/browse/ISPN-10835 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > Along with the work to document xsite on OpenShift, we need to productize and update the cross site replication docs for DG 8 bare metal servers. > CLI and REST docs should have procedures for xsite operations. > Xsite docs should have details on RELAY2 and site configuration + diagrams + JMX operations. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11129) High Availability for non-shared indexes on DIST caches

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-11129?page=com.atlassian.jira.plugi... ] Nistor Adrian updated ISPN-11129: --------------------------------- Status: Open (was: New) > High Availability for non-shared indexes on DIST caches > ------------------------------------------------------- > > Key: ISPN-11129 > URL: https://issues.redhat.com/browse/ISPN-11129 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > > 'Non-shared indexes' is a setup when each node has a local index backed by the file system, using either the near-real-time or the FS index managers. > For REPL caches, a full copy of the index is kept in each node. As long as at least on node is up the queries hit the local index which represents the full index of the data. > But non-shared indexes has some drawbacks for DIST caches: each node only indexes data that the node is the primary owner. If a node goes down, there is no redundancy. This issue aims to solve this issue at two levels: > * Indexing: replicated entries should be indexed for redundancy purposes. If a primary owner goes down, the entry is indexed in the backup owner. This should follow exactly the data distribution on the cache in terms of number of replicas and rebalancing > * Querying: query broadcast is currently used for non-shared indexes. If replicated entires start to be indexed, a mechanism will have to be used to avoid retuning repeated results, since currently the broadcast simply queries all the entries in each node and join the result. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11132) Data not indexed during state transfer in server mode

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-11132?page=com.atlassian.jira.plugi... ] Nistor Adrian commented on ISPN-11132: -------------------------------------- merged in 9.4.x > Data not indexed during state transfer in server mode > ----------------------------------------------------- > > Key: ISPN-11132 > URL: https://issues.redhat.com/browse/ISPN-11132 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 9.4.17.Final, 10.1.0.Final > Reporter: Gustavo Fernandes > Assignee: Nistor Adrian > Priority: Major > Fix For: 10.1.1.Final, 9.4.18.Final > > > A REPL cache with index auto-config, during State transfer is skipping index of data. > The order of events observed is: > CACHE_STARTING LIFECYCLE -> ST HAPPENS -> DATA WRITTEN -> CACHE STARTED LIFECYCLE > During data writes, the {{ProtobufValueWrapperIndexingInterceptor}} is activated by Hibernate Search and skips the indexing altogether since the {{ProtobufValueWrapperSearchWorkCreator}} is not used, and thus it cannot extract the descriptor from the entities. That search creator is only installed at cacheStarted phase. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10713) Upgrade SB version in the infinispan SB starter

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-10713?page=com.atlassian.jira.plugi... ] Katia Aresti updated ISPN-10713: -------------------------------- Description: Upgrade to latest 2.2.x and 10.1.Final (was: Upgrade to latest) > Upgrade SB version in the infinispan SB starter > ----------------------------------------------- > > Key: ISPN-10713 > URL: https://issues.redhat.com/browse/ISPN-10713 > Project: Infinispan > Issue Type: Component Upgrade > Components: Spring Integration > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > > Upgrade to latest 2.2.x and 10.1.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11142) Spring Boot Starter for Infinispan 10.1

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-11142?page=com.atlassian.jira.plugi... ] Katia Aresti closed ISPN-11142. ------------------------------- ISPN-10713 > Spring Boot Starter for Infinispan 10.1 > --------------------------------------- > > Key: ISPN-11142 > URL: https://issues.redhat.com/browse/ISPN-11142 > Project: Infinispan > Issue Type: Component Upgrade > Components: Spring Integration > Affects Versions: 10.1.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2020