July 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4661) TreeNode putIfAbsent implementation is different from what promised

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4661?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4661: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.0.0.Beta3 Resolution: Done > TreeNode putIfAbsent implementation is different from what promised > ------------------------------------------------------------------- > > Key: ISPN-4661 > URL: https://issues.jboss.org/browse/ISPN-4661 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Environment: JDK 1.7.0_60, Maven 3.2.2 > Reporter: Berkes Adam > Fix For: 8.0.0.Beta3 > > > In infinispan tree API (infinispan-tree, 6.0.2.Final) the TreeNode implementation's putIfAbsent method always return null which is different from the promise document for the method signature. It should return the value for the given key if exists. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5561) Problem in dealing with the HQL queries that contain string comparison operations, when it involves empty string as an operand

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5561?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5561: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1238866|https://bugzilla.redhat.com/show_bug.cgi?id=1238866] from POST to MODIFIED > Problem in dealing with the HQL queries that contain string comparison operations, when it involves empty string as an operand > ------------------------------------------------------------------------------------------------------------------------------ > > Key: ISPN-5561 > URL: https://issues.jboss.org/browse/ISPN-5561 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 7.2.0.Final > Environment: Infinispan version: Infinispan 7.2.0-Final > Operating System: Linux > Compatibility mode is enabled. > Indexing is enabled and 'autoconfig' parameter is set to true. > Reporter: Pavan Kundgol > Assignee: Adrian Nistor > Fix For: 8.0.0.Beta2, 7.2.4.Final, 8.0.0.Final > > > When a HQL query that involves string comparison operation with the empty string matching is executed through hot rod client(java), it is resulting in the following error, > org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[7] returned server error (status=0x85): org.hibernate.search.exception.EmptyQueryException: HSEARCH000146: The query string '' applied on field 'CITY' has no meaningful tokens to be matched. Validate the query input against the Analyzer applied on this field. > The same problem may also occur when the string matching operation involves a string containing certain special keywords(hibernate search stop words), as operands. > The problem seems to be assosiated with the the 'hibernate-hql-lucene' parser used by the 'infinispan-remote-query-server' module. The problem here is that the hibernate-hql-lucene parser is translating comparison operations directly into lucene keyword matching operations, irrespective of the field type, though the phrase matching is more appropriate for string fields. This leads to invalid query formation when the field in concern is of type string, and is matched against an empty string(or a string containing one or more hibernate search stop words). > For example, > the where condition city='' present in the following HQL query > select name from com.test.User where city='' > is tralated to lucene query, the hql-lucene parser is currently translating to > queryBuilder.keyword().onField("city").matching("").createQuery() > whereas recommended one is > queryBuilder.phrase().onField("city").sentence("").createQuery() > In the former way of translation, Hibernate Search query execution fails due to its usage of standard analyzer while executing the query. Hence, the problem can also be avoided by disabling the standard analyzer while executing the query. > queryBuilder.keyword().onField("city").ignoreAnalyzer().matching("").createQuery() > Preferred solution may be to enhance the 'hibernate-hql-lucene' library to do type specific translations, and to specifically translate the string comparison operations of hql query into phrase matching operations of lucene query(instead of keyword matching operations). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5626) Clean up missing parts for Distributed Streams

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5626?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5626: -------------------------------- Description: There are some things left over that need to still be done possibly # Investigate iterator parallel stream performance # Add support for key filter applying to cache loader # Add cache loader managed blocker # Add tests for skip & limit. # Add tests for containsValue requiring serialization overhead. # Change isEmpty to use findAny # Need to test a map/flatMap operation after an intermediate terminal operation such as sorted. This is to verify the iterator doesn't use the different map operation. # Add timeout for remote operations to be equal to replication sync timeout # Add new BitSetSet support to reduce segments footprint # Support concurrent activations properly (this is also an issue with state transfer) # Add tests for parallel streams with a cache loader (covers this change https://github.com/infinispan/infinispan/pull/3602/files#diff-00281a3984a...) # Rewrite cache loader to use a spliterator which allows for a more performant forEachRemaining and possibly better parallel split values was: There are some things left over that need to still be done possibly # Investigate iterator parallel stream performance # Add support for key filter applying to cache loader # Add cache loader managed blocker # Add tests for skip & limit. # Add tests for containsValue requiring serialization overhead. # Change isEmpty to use findAny # Need to test a map/flatMap operation after an intermediate terminal operation such as sorted. This is to verify the iterator doesn't use the different map operation. # Add timeout for remote operations to be equal to replication sync timeout # Add new BitSetSet support to reduce segments footprint # Support concurrent activations properly (this is also an issue with state transfer) # Add tests for parallel streams with a cache loader (covers this change https://github.com/infinispan/infinispan/pull/3602/files#diff-00281a3984a...) > Clean up missing parts for Distributed Streams > ---------------------------------------------- > > Key: ISPN-5626 > URL: https://issues.jboss.org/browse/ISPN-5626 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: William Burns > Assignee: William Burns > > There are some things left over that need to still be done possibly > # Investigate iterator parallel stream performance > # Add support for key filter applying to cache loader > # Add cache loader managed blocker > # Add tests for skip & limit. > # Add tests for containsValue requiring serialization overhead. > # Change isEmpty to use findAny > # Need to test a map/flatMap operation after an intermediate terminal operation such as sorted. This is to verify the iterator doesn't use the different map operation. > # Add timeout for remote operations to be equal to replication sync timeout > # Add new BitSetSet support to reduce segments footprint > # Support concurrent activations properly (this is also an issue with state transfer) > # Add tests for parallel streams with a cache loader (covers this change https://github.com/infinispan/infinispan/pull/3602/files#diff-00281a3984a...) > # Rewrite cache loader to use a spliterator which allows for a more performant forEachRemaining and possibly better parallel split values -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5643) Simplify handling of previous values

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5643?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5643: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3612 > Simplify handling of previous values > ------------------------------------ > > Key: ISPN-5643 > URL: https://issues.jboss.org/browse/ISPN-5643 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.Beta3 > > > There are 5 ways the user can influence whether the previous value is read from a store/remote node: > * unsafe.unreliableReturnValues > * IGNORE_RETURN_VALUES > * SKIP_CACHE_LOAD > * SKIP_REMOTE_LOOKUP > * CACHE_MODE_LOCAL > Currently the effect of each is slightly different, depending on whether the operation is conditional, whether it's a delta-aware write etc. This is how I think it should work: > * unsafe.unreliableReturnValues and IGNORE_RETURN_VALUES should skip reading the previous value only if it doesn't change the outcome of the operation (i.e. no effect for reads, conditional operations, or delta-aware). > * SKIP_CACHE_LOAD should *always* skip the cache loader. > * SKIP_REMOTE_LOOKUP and CACHE_MODE_LOCAL should *always* skip the remote lookup -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5643) Simplify handling of previous values

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5643?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5643: ------------------------------- Status: Open (was: New) > Simplify handling of previous values > ------------------------------------ > > Key: ISPN-5643 > URL: https://issues.jboss.org/browse/ISPN-5643 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.Beta3 > > > There are 5 ways the user can influence whether the previous value is read from a store/remote node: > * unsafe.unreliableReturnValues > * IGNORE_RETURN_VALUES > * SKIP_CACHE_LOAD > * SKIP_REMOTE_LOOKUP > * CACHE_MODE_LOCAL > Currently the effect of each is slightly different, depending on whether the operation is conditional, whether it's a delta-aware write etc. This is how I think it should work: > * unsafe.unreliableReturnValues and IGNORE_RETURN_VALUES should skip reading the previous value only if it doesn't change the outcome of the operation (i.e. no effect for reads, conditional operations, or delta-aware). > * SKIP_CACHE_LOAD should *always* skip the cache loader. > * SKIP_REMOTE_LOOKUP and CACHE_MODE_LOCAL should *always* skip the remote lookup -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5643) Simplify handling of previous values

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5643: ---------------------------------- Summary: Simplify handling of previous values Key: ISPN-5643 URL: https://issues.jboss.org/browse/ISPN-5643 Project: Infinispan Issue Type: Task Components: Core Affects Versions: 8.0.0.Beta2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 8.0.0.Beta3 There are 5 ways the user can influence whether the previous value is read from a store/remote node: * unsafe.unreliableReturnValues * IGNORE_RETURN_VALUES * SKIP_CACHE_LOAD * SKIP_REMOTE_LOOKUP * CACHE_MODE_LOCAL Currently the effect of each is slightly different, depending on whether the operation is conditional, whether it's a delta-aware write etc. This is how I think it should work: * unsafe.unreliableReturnValues and IGNORE_RETURN_VALUES should skip reading the previous value only if it doesn't change the outcome of the operation (i.e. no effect for reads, conditional operations, or delta-aware). * SKIP_CACHE_LOAD should *always* skip the cache loader. * SKIP_REMOTE_LOOKUP and CACHE_MODE_LOCAL should *always* skip the remote lookup -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5642) Reduce contention in the RPC timeout handling

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5642: ---------------------------------- Summary: Reduce contention in the RPC timeout handling Key: ISPN-5642 URL: https://issues.jboss.org/browse/ISPN-5642 Project: Infinispan Issue Type: Task Components: Core Affects Versions: 8.0.0.Beta2 Reporter: Dan Berindei Priority: Minor Fix For: 8.0.0.Final Most of the RPC timeout tasks are cancelled way before their timeout expires. This means the scheduler spends a lot of time reordering the elements of its DelayQueue. It should be possible to store the tasks with a long timeout (e.g. 1s) in a queue and only move them to the scheduler's priority queue when they have less than 1s to expiration (e.g. by a worker thread that runs every 0.5s) Storing all the tasks in a single queue may be impractical because the worker thread would have more and work to do as load increases and the RPCs take longer to finish, so a [hashed timing wheel|http://www.cse.wustl.edu/~cdgill/courses/cs6874/TimingWheels.ppt] may be needed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5640) Avoid a map lookup in SyncConfiguration.replTimeout()

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5640?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5640: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3610 > Avoid a map lookup in SyncConfiguration.replTimeout() > ----------------------------------------------------- > > Key: ISPN-5640 > URL: https://issues.jboss.org/browse/ISPN-5640 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 8.0.0.Beta3 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5641) Reduce contention in JGroupsAddressCache

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5641?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5641: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3610 > Reduce contention in JGroupsAddressCache > ---------------------------------------- > > Key: ISPN-5641 > URL: https://issues.jboss.org/browse/ISPN-5641 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 8.0.0.Beta3 > > > Avoid computeIfAbsent for existent entries, because it synchronizes on the entry. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5639) Avoid creating a Callable instance for RPC timeout handling

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5639?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5639: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3610 > Avoid creating a Callable instance for RPC timeout handling > ----------------------------------------------------------- > > Key: ISPN-5639 > URL: https://issues.jboss.org/browse/ISPN-5639 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.0.0.Beta3 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2015