July 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5603) Make BlockingTaskAwareExecutorService.checkForReadyTasks() asynchronous

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5603?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5603: ------------------------------ Fix Version/s: 8.0.0.Beta2 > Make BlockingTaskAwareExecutorService.checkForReadyTasks() asynchronous > ----------------------------------------------------------------------- > > Key: ISPN-5603 > URL: https://issues.jboss.org/browse/ISPN-5603 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 8.0.0.Beta2 > > > With the new locking, when locks are released we need to unblock possible queued commands waiting for the lock. Since this method can be invoked quite often, it is not desire to have the invocation thread doing the checks and moving tasks (and they can be executed if configured with RunCallersPolicy). > Moving the check to a different thread is needed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5603) Make BlockingTaskAwareExecutorService.checkForReadyTasks() asynchronous

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-5603: --------------------------------- Summary: Make BlockingTaskAwareExecutorService.checkForReadyTasks() asynchronous Key: ISPN-5603 URL: https://issues.jboss.org/browse/ISPN-5603 Project: Infinispan Issue Type: Sub-task Components: Core Reporter: Pedro Ruivo Assignee: Pedro Ruivo With the new locking, when locks are released we need to unblock possible queued commands waiting for the lock. Since this method can be invoked quite often, it is not desire to have the invocation thread doing the checks and moving tasks (and they can be executed if configured with RunCallersPolicy). Moving the check to a different thread is needed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5603) Make BlockingTaskAwareExecutorService.checkForReadyTasks() asynchronous

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5603?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5603: ------------------------------ Status: Open (was: New) > Make BlockingTaskAwareExecutorService.checkForReadyTasks() asynchronous > ----------------------------------------------------------------------- > > Key: ISPN-5603 > URL: https://issues.jboss.org/browse/ISPN-5603 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > > With the new locking, when locks are released we need to unblock possible queued commands waiting for the lock. Since this method can be invoked quite often, it is not desire to have the invocation thread doing the checks and moving tasks (and they can be executed if configured with RunCallersPolicy). > Moving the check to a different thread is needed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 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: 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)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5602) Create timeout scheduler executor

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5602?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5602: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3580 > Create timeout scheduler executor > --------------------------------- > > Key: ISPN-5602 > URL: https://issues.jboss.org/browse/ISPN-5602 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 8.0.0.Beta2 > > > With the new locking scheme, no threads wait for the lock to be acquired or timed out. Instead, they are notified when the lock state changes. Since the lock could be acquired for long period, we need a scheduler to schedule timeout checks, otherwise, operation could wait for a long period until they are notified. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5602) Create timeout scheduler executor

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5602?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5602: ------------------------------ Fix Version/s: 8.0.0.Beta2 > Create timeout scheduler executor > --------------------------------- > > Key: ISPN-5602 > URL: https://issues.jboss.org/browse/ISPN-5602 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 8.0.0.Beta2 > > > With the new locking scheme, no threads wait for the lock to be acquired or timed out. Instead, they are notified when the lock state changes. Since the lock could be acquired for long period, we need a scheduler to schedule timeout checks, otherwise, operation could wait for a long period until they are notified. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5602) Create timeout scheduler executor

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5602?page=com.atlassian.jira.plugin.... ] Pedro Ruivo reassigned ISPN-5602: --------------------------------- Assignee: Pedro Ruivo > Create timeout scheduler executor > --------------------------------- > > Key: ISPN-5602 > URL: https://issues.jboss.org/browse/ISPN-5602 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > > With the new locking scheme, no threads wait for the lock to be acquired or timed out. Instead, they are notified when the lock state changes. Since the lock could be acquired for long period, we need a scheduler to schedule timeout checks, otherwise, operation could wait for a long period until they are notified. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5602) Create timeout scheduler executor

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5602?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5602: ------------------------------ Status: Open (was: New) > Create timeout scheduler executor > --------------------------------- > > Key: ISPN-5602 > URL: https://issues.jboss.org/browse/ISPN-5602 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > > With the new locking scheme, no threads wait for the lock to be acquired or timed out. Instead, they are notified when the lock state changes. Since the lock could be acquired for long period, we need a scheduler to schedule timeout checks, otherwise, operation could wait for a long period until they are notified. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5602) Create timeout scheduler executor

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-5602: --------------------------------- Summary: Create timeout scheduler executor Key: ISPN-5602 URL: https://issues.jboss.org/browse/ISPN-5602 Project: Infinispan Issue Type: Sub-task Components: Core Reporter: Pedro Ruivo With the new locking scheme, no threads wait for the lock to be acquired or timed out. Instead, they are notified when the lock state changes. Since the lock could be acquired for long period, we need a scheduler to schedule timeout checks, otherwise, operation could wait for a long period until they are notified. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5467) Design new interceptor interfaces for sequential invocation

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/ISPN-5467?page=com.atlassian.jira.plugin.... ] Bela Ban commented on ISPN-5467: -------------------------------- Is there a design document somewhere that describes this change ? > Design new interceptor interfaces for sequential invocation > ----------------------------------------------------------- > > Key: ISPN-5467 > URL: https://issues.jboss.org/browse/ISPN-5467 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 7.2.1.Final > Reporter: Dan Berindei > Fix For: 8.0.0.Final > > > We need the interceptors to execute in sequence instead of using a stack in order to allow interrupting the execution of a command on one thread and continuing the execution on another thread. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 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