March 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9024) Remote query: disabling indexing for a type with @Indexed(false) still creates empty documents in index

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-9024: ----------------------------------- Summary: Remote query: disabling indexing for a type with @Indexed(false) still creates empty documents in index Key: ISPN-9024 URL: https://issues.jboss.org/browse/ISPN-9024 Project: Infinispan Issue Type: Bug Components: Remote Querying Affects Versions: 7.0.0.Final Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 9.3.0.Final When adding to cache protobuf encoded entries of types that are specifically annotated as @Indexed(false) we would expect that nothing is added to the index. But a document with no fields is added instead, cluttering the index. This does not impact the correctness of query results but it impacts performance because every put operation touches the index even if not required. This bug is a consequence of some limitations of the integration point between infinispan and hibernate search: the FieldBridge api. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9020) Remote query: disabling indexing for a type with @Indexed(false) still creates empty documents in index

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9020?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-9020: -------------------------------- Description: When adding to cache protobuf encoded entries of types that are specifically annotated as @Indexed(false) we would expect that nothing is added to the index. But a document with no fields is added instead, cluttering the index. This does not impact the correctness of query results but it impacts performance because every put operation touches the index even if not required. This bug is a consequence of some limitations of the integration point between infinispan and hibernate search: the FieldBridge api. (was: When adding to cache protobuf encoded entries of types that are specifically annotated as @Indexed(false) we would expect that nothing is added to the index. But a document with no fields is added instead, cluttering the index. This does not impact the correctness of query results but it impacts performance because every put operation touches the index even if not required.) > Remote query: disabling indexing for a type with @Indexed(false) still creates empty documents in index > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-9020 > URL: https://issues.jboss.org/browse/ISPN-9020 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.3.0.Final > > > When adding to cache protobuf encoded entries of types that are specifically annotated as @Indexed(false) we would expect that nothing is added to the index. But a document with no fields is added instead, cluttering the index. This does not impact the correctness of query results but it impacts performance because every put operation touches the index even if not required. This bug is a consequence of some limitations of the integration point between infinispan and hibernate search: the FieldBridge api. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9020) Remote query: disabling indexing for a type with @Indexed(false) still creates empty documents in index

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9020?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-9020: -------------------------------- Description: When adding to cache protobuf encoded entries of types that are specifically annotated as @Indexed(false) we would expect that nothing is added to the index. But a document with no fields is added instead, cluttering the index. This does not impact the correctness of query results but it impacts performance because every put operation touches the index even if not required. (was: When adding to cache types that are specifically marked as @Indexed(false) we would expect that nothing is added to the index. A document with no fields is added instead cluttering the index. This does not impact the result of queries.) > Remote query: disabling indexing for a type with @Indexed(false) still creates empty documents in index > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-9020 > URL: https://issues.jboss.org/browse/ISPN-9020 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.3.0.Final > > > When adding to cache protobuf encoded entries of types that are specifically annotated as @Indexed(false) we would expect that nothing is added to the index. But a document with no fields is added instead, cluttering the index. This does not impact the correctness of query results but it impacts performance because every put operation touches the index even if not required. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9003: -------------------------------- Fix Version/s: 9.3.0.Beta1 > Clustered maxIdle expiration > ---------------------------- > > Key: ISPN-9003 > URL: https://issues.jboss.org/browse/ISPN-9003 > Project: Infinispan > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: William Burns > Fix For: 9.3.0.Beta1, 9.3.0.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9003: -------------------------------- Fix Version/s: 9.3.0.Final > Clustered maxIdle expiration > ---------------------------- > > Key: ISPN-9003 > URL: https://issues.jboss.org/browse/ISPN-9003 > Project: Infinispan > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: William Burns > Fix For: 9.3.0.Beta1, 9.3.0.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.... ] William Burns edited comment on ISPN-9003 at 3/29/18 11:04 AM: --------------------------------------------------------------- Talking with [~NadirX] we believe the best approach may be a consensus based removal of maxIdle entries. That is it will do the following things 1. Read occurs on node where maxIdle is expired and sends request to primary owner (blocks the read) 2. Primary owner locks the key 3. Primary sends message to all nodes asking if entry is expired due to maxIdle (also updates the updated time on all keys - just in case it isn't expired) 4. Primary receives responses to decide if it is expired 5a. Primary responds to read node and tells them if it was expired 5b. Primary removes from all nodes if it was expired 6. Cluster wide expiration occurs if necessary allowing for listeners to be invoked (including cluster listeners - which we didn't do before) The above approach gives no overhead for reads when the entry is not present and is not expired. The only overhead is if a node finds that the entry was expired via maxIdle and then must block to confirm if it should be removed. However the chance of this occurring seems a bit low depending on what maxIdle was set to. If the expiration reaper finds the expired entry first it will properly update its timestamps or remove as needed. Another side effect of this is that maxIdle may be refreshed for all entries that are transferred via state transfer since I don't think the access time is currently replicated when state transfer occurs. was (Author: william.burns): Talking with [~NadirX] we believe the best approach may be a consensus based removal of maxIdle entries. That is it will do the following things 1. Read occurs on node where maxIdle is expired and sends request to primary owner (blocks the read) 2. Primary owner locks the key 3. Primary sends message to all nodes asking if entry is expired due to maxIdle (also updates the updated time on all keys - just in case it isn't expired) 4. Primary receives responses and if all say it is expired it will remove the entry 5a. Primary responds to read node and tells them if it was expired 5b. Primary removes from all nodes if it was expired 6. Cluster wide expiration occurs if necessary allowing for listeners to be invoked (including cluster listeners - which we didn't do before) The above approach gives no overhead for reads when the entry is not present and is not expired. The only overhead is if a node finds that the entry was expired via maxIdle and then must block to confirm if it should be removed. However the chance of this occurring seems a bit low depending on what maxIdle was set to. If the expiration reaper finds the expired entry first it will properly update its timestamps or remove as needed. Another side effect of this is that maxIdle may be refreshed for all entries that are transferred via state transfer since I don't think the access time is currently replicated when state transfer occurs. > Clustered maxIdle expiration > ---------------------------- > > Key: ISPN-9003 > URL: https://issues.jboss.org/browse/ISPN-9003 > Project: Infinispan > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: William Burns > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9003: -------------------------------- Status: Open (was: New) > Clustered maxIdle expiration > ---------------------------- > > Key: ISPN-9003 > URL: https://issues.jboss.org/browse/ISPN-9003 > Project: Infinispan > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: William Burns > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.... ] Work on ISPN-9003 started by William Burns. ------------------------------------------- > Clustered maxIdle expiration > ---------------------------- > > Key: ISPN-9003 > URL: https://issues.jboss.org/browse/ISPN-9003 > Project: Infinispan > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: William Burns > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-9003: ------------------------------------- Talking with [~NadirX] we believe the best approach may be a consensus based removal of maxIdle entries. That is it will do the following things 1. Read occurs on node where maxIdle is expired and sends request to primary owner (blocks the read) 2. Primary owner locks the key 3. Primary sends message to all nodes asking if entry is expired due to maxIdle (also updates the updated time on all keys - just in case it isn't expired) 4. Primary receives responses and if all say it is expired it will remove the entry 5a. Primary responds to read node and tells them if it was expired 5b. Primary removes from all nodes if it was expired 6. Cluster wide expiration occurs if necessary allowing for listeners to be invoked (including cluster listeners - which we didn't do before) The above approach gives no overhead for reads when the entry is not present and is not expired. The only overhead is if a node finds that the entry was expired via maxIdle and then must block to confirm if it should be removed. However the chance of this occurring seems a bit low depending on what maxIdle was set to. If the expiration reaper finds the expired entry first it will properly update its timestamps or remove as needed. Another side effect of this is that maxIdle may be refreshed for all entries that are transferred via state transfer since I don't think the access time is currently replicated when state transfer occurs. > Clustered maxIdle expiration > ---------------------------- > > Key: ISPN-9003 > URL: https://issues.jboss.org/browse/ISPN-9003 > Project: Infinispan > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: William Burns > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6161) Indexes should be created only for annotated message types

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6161?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-6161: ------------------------------------- This change is too big for a 9.x, should wait for 10. Until then I propose to have an option to disable the old behaviour but keep the default the same: this is implemented as ISPN-9021 > Indexes should be created only for annotated message types > ---------------------------------------------------------- > > Key: ISPN-6161 > URL: https://issues.jboss.org/browse/ISPN-6161 > Project: Infinispan > Issue Type: Task > Components: Remote Querying > Reporter: Tristan Tarrant > Assignee: Adrian Nistor > Fix For: 9.3.0.Final > > > Modify behaviour of indexing for protobuf entities: Current behaviour is: if the message types is not annotated then we index all its fields; if some fields are annotated then index those fields only. New behaviour: index only the annotated fields. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 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 March 2018