May 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3795: ----------------------------------- What is the purpose of running with indexing mode {{ALL}}/{{LOCAL_ONLY}} when the cache is not replicated (therefore a node may be non-owner)? Shouldn't we rather prohibit such configuration completely, when we know that it won't work? > QueryInterceptor incorrectly relies on the return value of a RemoveCommand > -------------------------------------------------------------------------- > > Key: ISPN-3795 > URL: https://issues.jboss.org/browse/ISPN-3795 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > > QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index. > But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index. > QueryInterceptor should probably use the previous value from the context entries to update the index instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7837) ClusteredQuery throws NPE if any local index is empty

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7837?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7837: ------------------------------------ Status: Open (was: New) > ClusteredQuery throws NPE if any local index is empty > ----------------------------------------------------- > > Key: ISPN-7837 > URL: https://issues.jboss.org/browse/ISPN-7837 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 9.0.0.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > The ClusteredQuery API expects that all local indexes are populated with documents. With the setting Index.LOCAL, it's possible to index all documents in a single node (by only executing puts in this node), leaving all the other nodes empty. Exception thrown: > {noformat} > Caused by: java.lang.NullPointerException > at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.collectKeys(CQCreateEagerQuery.java:37) > at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.perform(CQCreateEagerQuery.java:25) > at org.infinispan.query.clustered.ClusteredQueryCommand.perform(ClusteredQueryCommand.java:114) > at org.infinispan.query.clustered.ClusteredQueryCommand.invokeAsync(ClusteredQueryCommand.java:109) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5876) Pre-commit cache invalidation creates stale cache vulnerability

by Bui Van Nghiem (JIRA)

[ https://issues.jboss.org/browse/ISPN-5876?page=com.atlassian.jira.plugin.... ] Bui Van Nghiem commented on ISPN-5876: -------------------------------------- Hi, We are also facing the same problem at WF 10.1.0.Final with Infinispan 8.2.6. Can you also commit this change https://github.com/infinispan/infinispan/pull/3888 on 8.2.x so that we can have an offical fix on 8.2.7 > Pre-commit cache invalidation creates stale cache vulnerability > --------------------------------------------------------------- > > Key: ISPN-5876 > URL: https://issues.jboss.org/browse/ISPN-5876 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.2.7.Final > Reporter: Stephen Fikes > Assignee: Galder Zamarreño > Fix For: 5.2.15.Final, 8.1.0.Beta1, 8.1.0.Final > > > In a cluster where Infinispan serves as the level 2 cache for Hibernate (configured for invalidation), because invalidation requests for modified entities are sent *before* database commit, it is possible for nodes receiving the invalidation request to perform eviction and then (due to "local" read requests) reload the evicted entities prior to the time the database commit takes place in the server where the entity was modified. > Consequently, other servers in the cluster may contain data that remains stale until a subsequent change in another server or until the entity times out from lack of use. > It isn't easy to write a testcase for this - it required manual intervention to reproduce - but can be seen with any entity class, cluster, etc. (at least using Oracle - results may vary with specific databases) so I've not attached a testcase. The issue can be seen/understood by code inspection (i.e. the timing of invalidation vs. database commit). That said, my test consisted of a two node cluster and I used Byteman rules to delay database commit of a change to an entity (with an optimistic version property) long enough in "server 1" for eviction to complete and a subsequent re-read (by a worker thread on behalf of an EJB) to take place in "server 2". Following the re-read in "server 2", I the database commit proceeds in "server 1" and "server 2" now has a stale copy of the entity in cache. > One option is pessimistic locking which will block any read attempt until the DB commit completes. It is not feasible, however, for many applications to use pessimistic locking for all reads as this can have a severe impact on concurrency - and is the reason for using optimistic version control. But due to the early timing of invalidation broadcast (*before* database commit, while the data is not yet stale), optimistic locking is insufficient to guard against "permanently" stale data. We did see that some databases default to blocking repeatable reads even outside of transactions and without explicit lock requests. Oracle does not provide such a mode. So, all reads must be implemented to use pessimistic locks (which must be enclosed in explicit transactions - (b)locking reads are disallowed when autocommit=true in Oracle) and this could require significant effort (re-writes) to use pessimistic reads throughout - in addition to the performance issues this can introduce. > If broadcast of an invalidation message always occurs *after* database commit, optimistic control attributes are sufficient to block attempts to write stale data and though a few failures may occur (as they would in a single server with multiple active threads), it can be known that the stale data will be removed in some finite period. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6147) Provide option to invalidate on commit

by Bui Van Nghiem (JIRA)

[ https://issues.jboss.org/browse/ISPN-6147?page=com.atlassian.jira.plugin.... ] Bui Van Nghiem commented on ISPN-6147: -------------------------------------- Can we also revert that change on 8.2.x branch also, we are facing this on WF10.1.0.Final > Provide option to invalidate on commit > -------------------------------------- > > Key: ISPN-6147 > URL: https://issues.jboss.org/browse/ISPN-6147 > Project: Infinispan > Issue Type: Enhancement > Components: Transactions > Affects Versions: 5.2.14.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.2.18.Final > > > For 5.2.x, provide an option to enable invalidation messages to be sent at commit time. This issue is related to ISPN-5876 where we changed the default behaviour to send invalidation messages at commit time. This created issues in the 5.2.x branch and instead it was decided that the fix should be reverted and instead provide an option to change the default behaviour to invalidate at commit time controlled by a system property. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-31) Add support for packed repeated fields

by Adrian Nistor (JIRA)

Adrian Nistor created IPROTO-31: ----------------------------------- Summary: Add support for packed repeated fields Key: IPROTO-31 URL: https://issues.jboss.org/browse/IPROTO-31 Project: Infinispan ProtoStream Issue Type: Feature Request Reporter: Adrian Nistor See https://developers.google.com/protocol-buffers/docs/encoding#packed -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-31) Add support for packed repeated fields

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/IPROTO-31?page=com.atlassian.jira.plugin.... ] Adrian Nistor reassigned IPROTO-31: ----------------------------------- Assignee: Adrian Nistor > Add support for packed repeated fields > -------------------------------------- > > Key: IPROTO-31 > URL: https://issues.jboss.org/browse/IPROTO-31 > Project: Infinispan ProtoStream > Issue Type: Feature Request > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > See https://developers.google.com/protocol-buffers/docs/encoding#packed -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-31) Add support for packed repeated fields

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/IPROTO-31?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated IPROTO-31: -------------------------------- Status: Open (was: New) > Add support for packed repeated fields > -------------------------------------- > > Key: IPROTO-31 > URL: https://issues.jboss.org/browse/IPROTO-31 > Project: Infinispan ProtoStream > Issue Type: Feature Request > Reporter: Adrian Nistor > > See https://developers.google.com/protocol-buffers/docs/encoding#packed -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7837) ClusteredQuery throws NPE if any local index is empty

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7837?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes reassigned ISPN-7837: --------------------------------------- Assignee: Gustavo Fernandes > ClusteredQuery throws NPE if any local index is empty > ----------------------------------------------------- > > Key: ISPN-7837 > URL: https://issues.jboss.org/browse/ISPN-7837 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 9.0.0.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > The ClusteredQuery API expects all local index are populated with documents. With the setting Index.LOCAL, it's possible to index all documents in a single node (by only executing puts in this node), leaving all the other nodes empty. Exception thrown: > {noformat} > Caused by: java.lang.NullPointerException > at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.collectKeys(CQCreateEagerQuery.java:37) > at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.perform(CQCreateEagerQuery.java:25) > at org.infinispan.query.clustered.ClusteredQueryCommand.perform(ClusteredQueryCommand.java:114) > at org.infinispan.query.clustered.ClusteredQueryCommand.invokeAsync(ClusteredQueryCommand.java:109) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7837) ClusteredQuery throws NPE if any local index is empty

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7837?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7837: ------------------------------------ Description: The ClusteredQuery API expects that all local indexes are populated with documents. With the setting Index.LOCAL, it's possible to index all documents in a single node (by only executing puts in this node), leaving all the other nodes empty. Exception thrown: {noformat} Caused by: java.lang.NullPointerException at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.collectKeys(CQCreateEagerQuery.java:37) at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.perform(CQCreateEagerQuery.java:25) at org.infinispan.query.clustered.ClusteredQueryCommand.perform(ClusteredQueryCommand.java:114) at org.infinispan.query.clustered.ClusteredQueryCommand.invokeAsync(ClusteredQueryCommand.java:109) at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:101) at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99) at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71) at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40) {noformat} was: The ClusteredQuery API expects all local index are populated with documents. With the setting Index.LOCAL, it's possible to index all documents in a single node (by only executing puts in this node), leaving all the other nodes empty. Exception thrown: {noformat} Caused by: java.lang.NullPointerException at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.collectKeys(CQCreateEagerQuery.java:37) at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.perform(CQCreateEagerQuery.java:25) at org.infinispan.query.clustered.ClusteredQueryCommand.perform(ClusteredQueryCommand.java:114) at org.infinispan.query.clustered.ClusteredQueryCommand.invokeAsync(ClusteredQueryCommand.java:109) at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:101) at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99) at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71) at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40) {noformat} > ClusteredQuery throws NPE if any local index is empty > ----------------------------------------------------- > > Key: ISPN-7837 > URL: https://issues.jboss.org/browse/ISPN-7837 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 9.0.0.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > The ClusteredQuery API expects that all local indexes are populated with documents. With the setting Index.LOCAL, it's possible to index all documents in a single node (by only executing puts in this node), leaving all the other nodes empty. Exception thrown: > {noformat} > Caused by: java.lang.NullPointerException > at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.collectKeys(CQCreateEagerQuery.java:37) > at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.perform(CQCreateEagerQuery.java:25) > at org.infinispan.query.clustered.ClusteredQueryCommand.perform(ClusteredQueryCommand.java:114) > at org.infinispan.query.clustered.ClusteredQueryCommand.invokeAsync(ClusteredQueryCommand.java:109) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:101) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7837) ClusteredQuery throws NPE if any local index is empty

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-7837: --------------------------------------- Summary: ClusteredQuery throws NPE if any local index is empty Key: ISPN-7837 URL: https://issues.jboss.org/browse/ISPN-7837 Project: Infinispan Issue Type: Bug Components: Embedded Querying Affects Versions: 9.0.0.Final Reporter: Gustavo Fernandes The ClusteredQuery API expects all local index are populated with documents. With the setting Index.LOCAL, it's possible to index all documents in a single node (by only executing puts in this node), leaving all the other nodes empty. Exception thrown: {noformat} Caused by: java.lang.NullPointerException at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.collectKeys(CQCreateEagerQuery.java:37) at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.perform(CQCreateEagerQuery.java:25) at org.infinispan.query.clustered.ClusteredQueryCommand.perform(ClusteredQueryCommand.java:114) at org.infinispan.query.clustered.ClusteredQueryCommand.invokeAsync(ClusteredQueryCommand.java:109) at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:101) at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99) at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71) at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40) {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 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 May 2017