July 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-12172) Make the number of segments dynamic

by Dan Berindei (Jira)

Dan Berindei created ISPN-12172: ----------------------------------- Summary: Make the number of segments dynamic Key: ISPN-12172 URL: https://issues.redhat.com/browse/ISPN-12172 Project: Infinispan Issue Type: Bug Components: Configuration, Core Affects Versions: 11.0.1.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 12.0.0.Final Now that the data container and stores store segment information, it's becoming harder and harder to change the number of segments to accommodate a growth in the number of nodes and preserve all the data. We should investigate removing the {{numSegments}} configuration attribute and using an {{effectiveNumSegments}} that is the first power of 2 that's bigger than 10 * <cluster size> (customizable, maybe?) and at least as big as the previous {{effectiveNumSegments}}. The number of segments increase would be decided by the coordinator on join and would require state transfer, as {{SyncConsistentHashFactory}} would not assign the split segments to exactly the same owners (although it would have to be pretty close in order to make this practical). We would like to avoid updating the segment of every persisted entry on {{effectiveNumSegments}} changes, so the segment stored in persisted entries should be computed based on the maximum value we will allow for {{effectiveNumSegments}}, e.g. 2^16. We would then use a shift+mask to obtain the "effective segment" of the key, and range queries when obtaining all the keys in a segment. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12171) Set store segmented attribute dynamically based upon store characteristics

by Will Burns (Jira)

Will Burns created ISPN-12171: --------------------------------- Summary: Set store segmented attribute dynamically based upon store characteristics Key: ISPN-12171 URL: https://issues.redhat.com/browse/ISPN-12171 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Reporter: Will Burns Fix For: 12.0.0.Final We now have the new Store SPI which has the `characteristics` method which allows a store to publish what operations/configurations it supports. We should utilize this to determine if a store is segmented or not when the user doesn't specify the configuration value. If a Store can dynamically change supporting the segmentation characteristic it should log a message or possibly error if needed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12141) Docs: Updates from downstream review

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-12141?page=com.atlassian.jira.plugi... ] Donald Naro closed ISPN-12141. ------------------------------ > Docs: Updates from downstream review > ------------------------------------ > > Key: ISPN-12141 > URL: https://issues.redhat.com/browse/ISPN-12141 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > Fix For: 11.0.2.Final, 12.0.0.Dev02 > > > Need to incorporate several pieces of review feedback from downstream. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12136) [9.4.x] Docs: Update deployment structure xml to access user classes

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-12136?page=com.atlassian.jira.plugi... ] Donald Naro closed ISPN-12136. ------------------------------ > [9.4.x] Docs: Update deployment structure xml to access user classes > -------------------------------------------------------------------- > > Key: ISPN-12136 > URL: https://issues.redhat.com/browse/ISPN-12136 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Affects Versions: 9.4.19.Final > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > Fix For: 9.4.20.Final > > > Users must update jboss-deployment-structure.xml otherwise it is not possible to access user classes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12170) Query - Stop encoding the segment ID in document IDs

by Yoann Rodière (Jira)

[ https://issues.redhat.com/browse/ISPN-12170?page=com.atlassian.jira.plugi... ] Yoann Rodière updated ISPN-12170: --------------------------------- Summary: Query - Stop encoding the segment ID in document IDs (was: Query - Stop encoding the routing key in document IDs) > Query - Stop encoding the segment ID in document IDs > ---------------------------------------------------- > > Key: ISPN-12170 > URL: https://issues.redhat.com/browse/ISPN-12170 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying, Remote Querying > Affects Versions: 12.0.0.Dev01 > Reporter: Yoann Rodière > Priority: Major > Fix For: 12.0.0.Dev02 > > > We're currently relying on a hack to determine routing keys for indexed documents in Infinispan Query. That is, we concatenate the ID with the segment ID, and use a routing key bridge to extract the segment ID and use it as a routing key. > > A nasty side-effect is that we include the segment ID in the ID of indexed documents in the index. > > With Hibernate Search 6.0.0.Beta9, this won't be necessary anymore: we'll be able to pass the segment ID (routing key) to Hibernate Search directly. This means we'll be able to remove the hack and to use cleaner document IDs. > > This removal means documents will have a different ID, and thus any existing index will have to be rebuilt. Thus this should be done ASAP. > > See the implementation of RoutingKeyBridge in Infinispan, and see https://hibernate.atlassian.net/browse/HSEARCH-3891 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12170) Query - Stop encoding the segment ID in document IDs

by Yoann Rodière (Jira)

[ https://issues.redhat.com/browse/ISPN-12170?page=com.atlassian.jira.plugi... ] Yoann Rodière updated ISPN-12170: --------------------------------- Description: We're currently relying on a hack to determine routing keys for indexed documents in Infinispan Query. That is, we concatenate the ID with the segment ID, and use a routing key bridge to extract the segment ID then use it as a routing key. A nasty side-effect is that we include the segment ID in the ID of indexed documents in the index. With Hibernate Search 6.0.0.Beta9, this won't be necessary anymore: we'll be able to pass the segment ID (routing key) to Hibernate Search directly. This means we'll be able to remove the hack and to use cleaner document IDs. This removal means documents will have a different ID, and thus any existing index will have to be rebuilt. Thus this should be done ASAP. See the implementation of RoutingKeyBridge in Infinispan, and see [https://hibernate.atlassian.net/browse/HSEARCH-3891] was: We're currently relying on a hack to determine routing keys for indexed documents in Infinispan Query. That is, we concatenate the ID with the segment ID, and use a routing key bridge to extract the segment ID and use it as a routing key. A nasty side-effect is that we include the segment ID in the ID of indexed documents in the index. With Hibernate Search 6.0.0.Beta9, this won't be necessary anymore: we'll be able to pass the segment ID (routing key) to Hibernate Search directly. This means we'll be able to remove the hack and to use cleaner document IDs. This removal means documents will have a different ID, and thus any existing index will have to be rebuilt. Thus this should be done ASAP. See the implementation of RoutingKeyBridge in Infinispan, and see https://hibernate.atlassian.net/browse/HSEARCH-3891 > Query - Stop encoding the segment ID in document IDs > ---------------------------------------------------- > > Key: ISPN-12170 > URL: https://issues.redhat.com/browse/ISPN-12170 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying, Remote Querying > Affects Versions: 12.0.0.Dev01 > Reporter: Yoann Rodière > Priority: Major > Fix For: 12.0.0.Dev02 > > > We're currently relying on a hack to determine routing keys for indexed documents in Infinispan Query. That is, we concatenate the ID with the segment ID, and use a routing key bridge to extract the segment ID then use it as a routing key. > > A nasty side-effect is that we include the segment ID in the ID of indexed documents in the index. > > With Hibernate Search 6.0.0.Beta9, this won't be necessary anymore: we'll be able to pass the segment ID (routing key) to Hibernate Search directly. This means we'll be able to remove the hack and to use cleaner document IDs. > > This removal means documents will have a different ID, and thus any existing index will have to be rebuilt. Thus this should be done ASAP. > > See the implementation of RoutingKeyBridge in Infinispan, and see [https://hibernate.atlassian.net/browse/HSEARCH-3891] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12170) Query - Stop encoding the routing key in document IDs

by Yoann Rodière (Jira)

Yoann Rodière created ISPN-12170: ------------------------------------ Summary: Query - Stop encoding the routing key in document IDs Key: ISPN-12170 URL: https://issues.redhat.com/browse/ISPN-12170 Project: Infinispan Issue Type: Task Components: Embedded Querying, Remote Querying Affects Versions: 12.0.0.Dev01 Reporter: Yoann Rodière Fix For: 12.0.0.Dev02 We're currently relying on a hack to determine routing keys for indexed documents in Infinispan Query. That is, we concatenate the ID with the segment ID, and use a routing key bridge to extract the segment ID and use it as a routing key. A nasty side-effect is that we include the segment ID in the ID of indexed documents in the index. With Hibernate Search 6.0.0.Beta9, this won't be necessary anymore: we'll be able to pass the segment ID (routing key) to Hibernate Search directly. This means we'll be able to remove the hack and to use cleaner document IDs. This removal means documents will have a different ID, and thus any existing index will have to be rebuilt. Thus this should be done ASAP. See the implementation of RoutingKeyBridge in Infinispan, and see https://hibernate.atlassian.net/browse/HSEARCH-3891 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12141) Docs: Updates from downstream review

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12141?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12141: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 11.0.2.Final 12.0.0.Dev02 Resolution: Done > Docs: Updates from downstream review > ------------------------------------ > > Key: ISPN-12141 > URL: https://issues.redhat.com/browse/ISPN-12141 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > Fix For: 11.0.2.Final, 12.0.0.Dev02 > > > Need to incorporate several pieces of review feedback from downstream. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12169) Avoid to wrap the SearchMapping

by Fabio Massimo Ercoli (Jira)

Fabio Massimo Ercoli created ISPN-12169: ------------------------------------------- Summary: Avoid to wrap the SearchMapping Key: ISPN-12169 URL: https://issues.redhat.com/browse/ISPN-12169 Project: Infinispan Issue Type: Task Components: Embedded Querying, Remote Querying Affects Versions: 12.0.0.Dev01 Reporter: Fabio Massimo Ercoli Assignee: Fabio Massimo Ercoli Fix For: 12.0.0.Final Thanks to the fact that now the {{SerializationContext}} must contain all the indexed entities at cache starting time we can avoid to wrap the {{SearchMapping}} instance with a {{SearchMappingHolder}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12144) Operator Docs: Clarify xsite docs

by Donald Naro (Jira)

[ https://issues.redhat.com/browse/ISPN-12144?page=com.atlassian.jira.plugi... ] Donald Naro updated ISPN-12144: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Operator Docs: Clarify xsite docs > --------------------------------- > > Key: ISPN-12144 > URL: https://issues.redhat.com/browse/ISPN-12144 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > describe that XSite need the operator to work properly and show within the doc how it works > XSiteRepl DG8.1 is done with a single site master the "xsite-service" will forward all requests to the JGroups coordinator > the site-master is choosen by operator and the jgroups coordinator is used > operator will query all pods and tag the pod where coordinator run > if the coordinator dies, the operator finds the new coordinator/pod and tags that one. the service automatically updates and starts using the new pod -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2020