Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Response.Listener onQueued and threads
Small world Uwe :-)

Yes, as I said, the code in question already uses attributes.  The concern is, exactly where the code is that adds these attributes.  I'm trying to encapsulate logic into the HttpClient plugins (the listeners but could be whatever as needed).  Of course I could add these attributes when crafting the Request but such logic is outside the HttpClient internal processing chain (I want to avoid that).  And I can't intercept the chain and be on the same thread to get the data needed for those attributes (onQueue doesn't have this guarantee of same-thread).  Is there another plugin/callback API to intercept the Request on the same caller/invoker thread?

My next thing to investigate is to double-check that the Executor passed to Jetty is always a Solr managed Executor, which should be passing the ThreadLocal info of concern through to the next thread when Jetty uses the executor.

On Thu, Mar 13, 2025 at 1:42 PM Uwe Schindler via jetty-users <jetty-users@xxxxxxxxxxx> wrote:

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

Am 13.03.2025 um 03:11 schrieb David Smiley via jetty-users:
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 Smiley
Apache 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/
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users

Back to the top