sarkaramrit1993 commented on PR #5238: URL: https://github.com/apache/solr/pull/5238#issuecomment-6514267157
Heads-up on a change of approach here. Right now `onRequestEnd` runs on the request thread before the response is written, so anything a listener does adds to the client's latency and to QTime. That's fine for an in-memory top-N but not for a listener that writes to a store, which is the UBI case. I'm fixing that in the hook rather than leaving it to every listener. What's changing: - **Off the request thread.** Listeners run on a small worker fed by a bounded queue, like `AuditLoggerPlugin`'s async mode. A full queue drops the event and counts it in a metric, so a search never waits on a listener's work. - **Detached snapshot.** `SearchRequestInfo` drops `req`, `rsp` and `rb`, since they're closed by the time a listener runs. It carries plain values, and a listener can copy anything extra on the request thread through a cheap `capture` step. - **Reported time is QTime.** The hand-off moves to `SolrCore.postDecorateResponse`, after QTime is computed, so listeners get the exact header value. - **Listener errors stay off the request.** They're logged on the worker and never fail a search. Things I'm working through as part of it: - Dropping under load keeps searches safe, but Query Insights can miss queries while a node is overloaded. The lost count is exposed as a metric and the queue size is configurable. - UBI doc ids need the open searcher in local mode, so they stay in a `SearchComponent`, as #2452 does today. - One worker serves all listeners for now. It can be split per listener if a second real listener needs it. - The snapshot copies params on every search when a listener is registered. I'll cap the size and post p50/p99 numbers with and without a listener. I'll push this as new commits here, and I'm moving the PR back to draft until then. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
