January 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11128) IndexMode.PRIMARY_OWNER should index data from State Transfer if the index is non-shared

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11128?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11128: ------------------------------------- Summary: IndexMode.PRIMARY_OWNER should index data from State Transfer if the index is non-shared (was: IndexMode.PRIMARY_OWNER should index state transfer data if the index is non-shared) > IndexMode.PRIMARY_OWNER should index data from State Transfer if the index is non-shared > ---------------------------------------------------------------------------------------- > > Key: ISPN-11128 > URL: https://issues.redhat.com/browse/ISPN-11128 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 10.1.0.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > > The {{IndexMode.PRIMARY_OWNER}} strategy is suitable for single indexes cluster-wide, that happens when using {{InfinispanIndexManager}} and {{ElasticSearchIndexManager}}. On this case, an entry should be indexed only once since all new joining nodes will see the global index. > For the cases where the index is local to each node (near-real-time and file system index managers), the state transfer data should definitely be indexed, otherwise when ownership of a key changes the entry will be kept in the 'old' owner. -- 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)

Gustavo Fernandes created ISPN-11129: ---------------------------------------- Summary: 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 '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-7169) Add marker interface to determine if a store can be shared or not

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-7169?page=com.atlassian.jira.plugin... ] Dan Berindei commented on ISPN-7169: ------------------------------------ [~william.burns] I would suggest instead adding a method {{CacheLoader.accessMode()}}, that would return {{SHARED}}, {{PRIVATE}}, or {{BOTH}}. The default implementation would return {{BOTH}}, but concrete implementations would be encouraged to return {{SHARED}} or {{PRIVATE}}. If the store's access mode and the {{shared}} attribute in configuration disagree, we would throw an exception on startup, but if {{shared}} is missing in the configuration then we can use the store's access mode instead of defaulting to {{shared=false}}. I'm pretty sure {{DummyInMemoryStore}} is the only store that can reasonably be used both as a private store and as a shared store, and if we eventually decide to remove {{BOTH}} it's really easy to add a {{shared}} attribute specific to {{DummyInMemoryStore}}. > Add marker interface to determine if a store can be shared or not > ----------------------------------------------------------------- > > Key: ISPN-7169 > URL: https://issues.redhat.com/browse/ISPN-7169 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Will Burns > Priority: Major > > We should add a new marker interface to tell if a store can be shared or not. Then at configuration time if a store was marked as shared by the user but doesn't have the interface we can throw an exception explaining you should only share supported stores. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11128) IndexMode.PRIMARY_OWNER should index state transfer data if the index is non-shared

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11128?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11128: ------------------------------------- Description: The {{IndexMode.PRIMARY_OWNER}} strategy is suitable for single indexes cluster-wide, that happens when using {{InfinispanIndexManager}} and {{ElasticSearchIndexManager}}. On this case, an entry should be indexed only once since all new joining nodes will see the global index. For the cases where the index is local to each node (near-real-time and file system index managers), the state transfer data should definitely be indexed, otherwise when ownership of a key changes the entry will be kept in the 'old' owner. was: The {{IndexMode.PRIMARY_OWNER}} strategy is suitable for single indexes cluster-wide, that happens when using {{InfinispanIndexManager}} and {{ElasticSearchIndexManager}}. On this case, an entry should be indexed only once since all new joining nodes will see the global index. For the cases where the index is local to each node (near real time and file system index managers), the state transfer data should definitely be indexed, otherwise when ownership of a key changes the entry will be kept in the 'old' owner. > IndexMode.PRIMARY_OWNER should index state transfer data if the index is non-shared > ----------------------------------------------------------------------------------- > > Key: ISPN-11128 > URL: https://issues.redhat.com/browse/ISPN-11128 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 10.1.0.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > > The {{IndexMode.PRIMARY_OWNER}} strategy is suitable for single indexes cluster-wide, that happens when using {{InfinispanIndexManager}} and {{ElasticSearchIndexManager}}. On this case, an entry should be indexed only once since all new joining nodes will see the global index. > For the cases where the index is local to each node (near-real-time and file system index managers), the state transfer data should definitely be indexed, otherwise when ownership of a key changes the entry will be kept in the 'old' owner. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11128) IndexMode.PRIMARY_OWNER should index state transfer data if the index is non-shared

by Gustavo Fernandes (Jira)

Gustavo Fernandes created ISPN-11128: ---------------------------------------- Summary: IndexMode.PRIMARY_OWNER should index state transfer data if the index is non-shared Key: ISPN-11128 URL: https://issues.redhat.com/browse/ISPN-11128 Project: Infinispan Issue Type: Bug Components: Embedded Querying Affects Versions: 10.1.0.Final Reporter: Gustavo Fernandes Assignee: Gustavo Fernandes The {{IndexMode.PRIMARY_OWNER}} strategy is suitable for single indexes cluster-wide, that happens when using {{InfinispanIndexManager}} and {{ElasticSearchIndexManager}}. On this case, an entry should be indexed only once since all new joining nodes will see the global index. For the cases where the index is local to each node (near real time and file system index managers), the state transfer data should definitely be indexed, otherwise when ownership of a key changes the entry will be kept in the 'old' owner. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11127) Protocol servers don't pre-start caches when transport is disabled

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11127?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11127: ----------------------------------- Status: Open (was: New) > Protocol servers don't pre-start caches when transport is disabled > ------------------------------------------------------------------ > > Key: ISPN-11127 > URL: https://issues.redhat.com/browse/ISPN-11127 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 10.1.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.1.1.Final > > > The various protocol servers have different initialization steps to ensures that caches are pre-started which don't work in all cases. In particular the REST server doesn't pre-start caches and the Hot Rod server pre-starts only if the transport is enabled. > This should be handled uniformly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11127) Protocol servers don't pre-start caches when transport is disabled

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11127?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11127: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7716 > Protocol servers don't pre-start caches when transport is disabled > ------------------------------------------------------------------ > > Key: ISPN-11127 > URL: https://issues.redhat.com/browse/ISPN-11127 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 10.1.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.1.1.Final > > > The various protocol servers have different initialization steps to ensures that caches are pre-started which don't work in all cases. In particular the REST server doesn't pre-start caches and the Hot Rod server pre-starts only if the transport is enabled. > This should be handled uniformly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11126) Health check fails when authz is enabled and cache is not yet started

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11126?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11126: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7716 > Health check fails when authz is enabled and cache is not yet started > --------------------------------------------------------------------- > > Key: ISPN-11126 > URL: https://issues.redhat.com/browse/ISPN-11126 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management, REST > Affects Versions: 10.1.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.1.1.Final > > > When using predefined caches on a container with authorization, and the caches have not been started, the health handler for the cachemanager resource fails with an authorization error. > The call should be wrapped in a SecurityAction. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11127) Protocol servers don't pre-start caches when transport is disabled

by Tristan Tarrant (Jira)

Tristan Tarrant created ISPN-11127: -------------------------------------- Summary: Protocol servers don't pre-start caches when transport is disabled Key: ISPN-11127 URL: https://issues.redhat.com/browse/ISPN-11127 Project: Infinispan Issue Type: Bug Components: Server Affects Versions: 10.1.0.Final Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 10.1.1.Final The various protocol servers have different initialization steps to ensures that caches are pre-started which don't work in all cases. In particular the REST server doesn't pre-start caches and the Hot Rod server pre-starts only if the transport is enabled. This should be handled uniformly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11126) Health check fails when authz is enabled and cache is not yet started

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-11126?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-11126: ----------------------------------- Status: Open (was: New) > Health check fails when authz is enabled and cache is not yet started > --------------------------------------------------------------------- > > Key: ISPN-11126 > URL: https://issues.redhat.com/browse/ISPN-11126 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management, REST > Affects Versions: 10.1.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.1.1.Final > > > When using predefined caches on a container with authorization, and the caches have not been started, the health handler for the cachemanager resource fails with an authorization error. > The call should be wrapped in a SecurityAction. -- 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