almogtavor opened a new issue, #12318: URL: https://github.com/apache/lucene/issues/12318
### Description I'd like to use Lucene Monitor in a non-blocking IO application, and I'd like to know what is the recommended way of doing that. Currently, I match queries with the `ParallelMatcher` class, but since I'd like to migrate my application to work with Project Reactor, I'm worried about the usage of `BlockingQueue` inside `ParallelMatcher`. When using the Java `BlockingQueue` implementation, the `put()` method will block if the queue is full, and the `take()` method will block if the queue is currently empty. This can be an effective way to handle cases where producers might produce data faster than consumers can handle it or vice versa. However, when using reactive programming paradigms (such as in Project Reactor), blocking should be avoided as much as possible because it goes against the non-blocking nature of reactive systems. Blocking can lead to thread starvation and ultimately affect the performance and scalability of the application. I'd like to get some help with understanding if there's another `Matcher` that will fit my async needs, or shall I create one of my own for this? From what I've seen, the `PartitionMatcher` doesn't use `BlockingQueue` but still uses `future.get()`. I'd like to know the following: 1) Is there any `Matcher` that would work well inside a non-blocking IO application? If not, shall we create one? 2) Assuming there is a non-blocking IO `Matcher`, is there any other area where I need to be worried about my usage of Lucene Monitor blocking ( This includes any IO operations, synchronization points, or data structures that can block)? -- 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: issues-unsubscr...@lucene.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
