| Re: [jetty-users] Response.Listener onQueued and threads |
Hi David,
the official way in Jetty to pass around arbitrary information
tied to a request (in both the client and the server) is to use
attributes. If you have a request, you can set it with
attribute("solr.whatever", anything) and in the callback retrieve
it with getAttributes().get("solr.whatever"). As name for the
attribute it is preferred to use a classname/package name as key
to avoid clashes with jetty-internal attributes or those by other
handlers in the chain.
FYI, on the Solr server this should be done in exactly the same way. Basically the Servlet-API's request attributes (setATtribute/getAttribute) maps directly to the Request object in the jetty server, so can also be used to transport object referenmces during the request.
Uwe
We use ThreadLocals to pass contextual information, and to mark threads in most server thread-pools as "server threads". Based on this information in the thread talking to HttpClient, we potentially add certain metadata on the Jetty Request (attributes) so that it's seen soon in a Jetty onBegin callback that Solr has. Prior to me hacking on this part of Solr, this was done by Http2SolrClient (a wrapper around Jetty HttpClient). I tried to move this logic into an onQueue so that the HttpClient with its listeners would be more self-contained to be used in a place that isn't necessarily an Http2SolrClient. But if I can't add callbacks/listeners inside HttpClient that are guaranteed to run on the invoker thread, then I can't do this, at least not this way.
On Wed, Mar 12, 2025 at 8:18 PM Joakim Erdfelt <joakim.erdfelt@xxxxxxxxx> wrote:
First, why are you wanting this kind of thread specificity? Often times when someone explains what they need, as opposed to what they want to do, there's other options that the original OP didn't even know existed.
Know that Jetty Client processing of a request does not use a model of 1 thread per request, it is designed to be 100% async.
- Joakim
On Wed, Mar 12, 2025 at 5:57 PM David Smiley via jetty-users <jetty-users@xxxxxxxxxxx> wrote:
_______________________________________________Hello,
I work on Apache Solr, and at the moment I'm fiddling with the Jetty HttpClient it uses. HttpClient has a Request QueuedListener interface with an onQueued callback -- org.eclipse.jetty.client.api.Request.QueuedListener#onQueued
My hope was that this is called on the same thread that is issuing the request into HttpClient (it's "front door" so to speak) but I have evidence that it sometimes doesn't happen this way. I have a test that failed once but it's hard to reproduce. Assuming there's no guarantee on the thread used to call onQueued, and that it might not be the client/requesting thread, then can someone advise on how I might configure Jetty so as to make this different thread usage more reproducible so that I can come up with another approach to my problem and have more confidence I've ultimately fixed a regression?
~ David SmileyApache Lucene/Solr Search Developer
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________ jetty-users mailing list jetty-users@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
-- Uwe Schindler uschindler@xxxxxxxxxx ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr Bremen, Germany https://lucene.apache.org/ https://solr.apache.org/