[JBoss JIRA] (ISPN-7982) Ickle purely negative fulltext subqueries cause empty results
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-7982?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7982:
----------------------------------
Fix Version/s: 9.4.4.Final
(was: 9.4.3.Final)
> Ickle purely negative fulltext subqueries cause empty results
> -------------------------------------------------------------
>
> Key: ISPN-7982
> URL: https://issues.jboss.org/browse/ISPN-7982
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 9.0.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Adrian Nistor
> Priority: Major
> Fix For: 9.4.4.Final
>
>
> When using parethesis in an Ickle full text predicate, it can generate subqueries that are pure negative, e.g.
> {{from IspnEvent where (tags : ('tagA' and (not 'a0')))}}
> In Lucene, the query
> {{+tags:taga +(-tags:a0)}}
> is different from
> {{+tags:taga -tags:a0}}
> The latter works as expected, but the former brings empty results since Lucene does no support purely negative subqueries. In order for the former query to work, it needs to add all documents as another term to the subquery, for e.g. {{+tags:taga +(\*:\* -tags:a0)}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-8643) ClientConnectionPoolingTest.testMaxActiveReached random failures
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8643?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8643:
----------------------------------
Fix Version/s: 9.4.4.Final
(was: 9.4.3.Final)
> ClientConnectionPoolingTest.testMaxActiveReached random failures
> ----------------------------------------------------------------
>
> Key: ISPN-8643
> URL: https://issues.jboss.org/browse/ISPN-8643
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.2.0.Beta2
> Reporter: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 9.4.4.Final
>
>
> Looks like waiting for 1s for all the connections to be releases is not enough:
> {noformat}
> java.lang.AssertionError:
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:229)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:211)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:187)
> at org.infinispan.client.hotrod.ClientConnectionPoolingTest.testMaxActiveReached(ClientConnectionPoolingTest.java:208)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> http://ci.infinispan.org/job/Infinispan/job/master/336
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-8628) Simplify QueryEngine handling of Broadcast vs Fetch queries
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8628?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8628:
----------------------------------
Fix Version/s: 9.4.4.Final
(was: 9.4.3.Final)
> Simplify QueryEngine handling of Broadcast vs Fetch queries
> -----------------------------------------------------------
>
> Key: ISPN-8628
> URL: https://issues.jboss.org/browse/ISPN-8628
> Project: Infinispan
> Issue Type: Task
> Reporter: Gustavo Fernandes
> Assignee: Adrian Nistor
> Priority: Minor
> Fix For: 9.4.4.Final
>
>
> [~anistor] commented
> The existence of RemoteQueryDefinition and HsQueryRequest seems to be a symptom of misplaced responsibility. It all starts with QueryDefinition.initialize, which IMO should actually be placed inside QueryEngine, not QueryDefinition. Doing that refactoring will remove the need for RemoteQueryDefinition, which now exists just to differentiate between embedded and remote case, but that differentiation can be done inside the query engine itself. Also, HsQueryRequest is just a data holder that carries the return value of QueryEngine.createHsQuery. If QueryDefinition.initialize is moved to QueryEngine we would also not need this anymore.
> I did not think about it in detail but maybe we would also need to make QueryDefinition mutable for QueryEngine and immutable for external parties. In that case we can extract QueryDefinition as an immutable interface (exposing getters only) and it's implementation class could have package local setters accessible to QueryEngine only.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months