[
https://issues.apache.org/jira/browse/CXF-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14115519#comment-14115519
]
Andriy Redko commented on CXF-5938:
-----------------------------------
Hi Sergey,
Yes, sure, it is related to the complication mentioned in previous comment.
So the first thread-local variable holds the stack of the queries and by
initial design it is supposed to be the only thread-related variable required.
The 'visit' method also performs cleanup (or reset) of the query stack on each
call. Now, it worked fine except the non-primitive search condition case. In
the code of 'visit()' method you can see the calls like
'condition.accept(this)' which is basically the recursion: eventually it calls
'visit()' method of this visitor instance again (and so forth). And because
'visit()' cleans the query stack, it led to test failures. To solve the issue I
had to find a way to distinguish if the 'visit()' method is called by external
callee or it is nested call from the visitor itself, and that's why the second
thread-local variable appeared on the picture.
Another simpler solution would be to introduce the explicit 'reset()' method to
clean up query stack for current thread.
Thanks!
Best Regards,
Andriy Redko
> LuceneQueryVisitor is not reusable / not thread-safe
> ----------------------------------------------------
>
> Key: CXF-5938
> URL: https://issues.apache.org/jira/browse/CXF-5938
> Project: CXF
> Issue Type: Bug
> Components: Integration
> Affects Versions: 3.0.1
> Reporter: Andriy Redko
> Assignee: Andriy Redko
> Priority: Minor
> Fix For: 3.0.2
>
>
> LuceneQueryVisitor class is not really reusable in current implementation: it
> keeps the state of all parsed queries (which is generally fine) but it groups
> them by property name, returning the first query from the list all the time.
> That means running two search criteria like 'ct=java' and 'ct=websockets'
> causes the result of 'ct=java' to be returned in both cases (very easy
> reproducible).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
