[
https://issues.apache.org/jira/browse/CXF-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14115788#comment-14115788
]
Sergey Beryozkin commented on CXF-5938:
---------------------------------------
Hi Andriy
Sure, I still remember what happens when visit() is called from within visit()
:-).
IMHO we still need to have a single thread local (query stack) state only.
How about this approach: when a given thread exits a top level visit, i.e,
finishes the work, the state gets marked as 'closed'.
If the same thread enters a top-level visit() again and sees a 'closed' state
it gets cleaned-up.
In addition to that, I agree, we actually do need to have reset() introduced,
so that the client code can proactively clear the state. IMHO calling reset()
would need to be optional though. The state can also periodically clean up
itself to remove stale entries, but we can deal with the auto-cleanup later
on...
Does it sound reasonable, a single TL state + reset() ?
Thanks, Sergey
> 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)
