allthingssecurity opened a new pull request, #27639: URL: https://github.com/apache/camel/pull/27639
# Description [CAMEL-25506](https://issues.apache.org/jira/browse/CAMEL-25506) `LuceneQueryProducer` used one `LuceneSearcher` for all exchanges, and `LuceneSearcher` kept the reader, the `IndexSearcher` and the hits of the last query in fields. With concurrent exchanges one exchange could get the hits of another exchange's query (27 to 48 of 20000 queries in the new test on main), and every query's reader except the last one was left to the garbage collector. `doStop()` closed the endpoint's analyzer, so after a route restart every query failed with `AlreadyClosedException: this Analyzer is closed`; a stop before any query threw a `NullPointerException`. This change uses a `LuceneSearcher` per exchange (open, search, close in a `finally`) in `LuceneQueryProducer` and `LuceneQueryProcessor`, and `LuceneSearcher.close()` closes only its reader (null-safe), not the analyzer, which belongs to the endpoint or the registry. Code that uses `LuceneSearcher` directly must now close its analyzer itself. The `LuceneQueryProcessor` change is the same idiom and is covered only by the existing `LuceneQueryProcessorIT`. This is one of three independent camel-lucene fixes of the same batch (inserts after a restart, query producer state, per-endpoint configuration); they change different files and apply in any order. Tests: - New `LuceneQueryProducerLifecycleTest` in camel-lucene: a query after a route restart (deterministic), and 20000 concurrent queries for two terms on 8 threads, each checked against its own term (about 2 s; it cannot force the interleaving, it makes it very likely). - Without the change: `a query after the route was restarted must succeed ==> expected: <null> but was: <org.apache.lucene.store.AlreadyClosedException: this Analyzer is closed>` and `each query must get the hits of its own query, but 39 of 20000 did not` (both tests fail). - With the change, camel-lucene tests pass: `LuceneQueryProducerLifecycleTest` (2), `LuceneIndexAndQueryProducerIT` (4), `LuceneQueryProcessorIT` (2), 0 failures. Found with a TLA+ model of the producer and searcher (one action per field read/write, route stop/start): "every answer holds the hits of its own query" is violated in 7 steps with two threads, and "no query runs on a closed analyzer" in 9 steps (query, stop, start, query). I then reproduced it with the real component. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested camel-lucene, including the formatter and import-sort plugins. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
