Your best bet would be to do at Greg said and capture the actual request
failing on the wire using wireshark or tcpdump, or get a
HttpChannel.Listener[1] set up in the server so you can see what is
happening there.

Ultimately Jetty-9 is community end of life (a year ago today! [2]), and we
are only supporting it for customers of Webtide.  Most of our focus is on
getting Jetty-12 out the door, and then we'll reach out to other
open-source projects to try and help them get updated.  Once Jetty-12 is
released (which has support for both javax and jakartaee namespaces), we
will start spinning down support for Jetty-10 and Jetty-11 since Jetty-12
will be able to run everything from Jetty-9, Jetty-10 and Jetty-11 on
Java17.

[1]
https://github.com/eclipse/jetty.project/blob/jetty-9.4.48.v20220622/jetty-server/src/main/java/org/eclipse/jetty/server/HttpChannelListeners.java
[2] https://github.com/eclipse/jetty.project/issues/7958

cheers,
Jesse

--
jesse mcconnell
[email protected]


On Thu, Jun 1, 2023 at 4:04 PM Shawn Heisey <[email protected]> wrote:

> On 6/1/23 13:25, Jesse McConnell wrote:
> > Friction points between Jetty and Solr on the server side are possible
> > or, more likely, an issue with the client.  With Jetty, it is never a
> > good idea to double configuration values and see what happens,
> > especially regarding HTTP configurations. You can bump header buffer
> > sizes easily, but thread counts and pools should only be raised based on
> > careful analysis and measurements.
>
> There are only two things I change from whatever SolrJ does by default:
> I set it to use http/1.1, and add basic authentication credentials.
> This is done with SolrJ methods ... I do not create or access the Jetty
> client directly.  No other client settings, including thread counts,
> have been touched.
>
> I have asked SolrJ to always send POST requests, so I think the http
> header buffer size is unlikely to be the problem.  But maybe I am wrong.
>
> I am using the latest SolrJ - 9.2.1.  This pulls in Jetty Client version
> 10.0.13.  I have also tried upgrading all the Jetty dependencies to
> 10.0.15 and there was no change.
>
> At some point Solr is likely upgrading both the Jetty client and server
> beyond version 10, but I do not know when that is going to happen.
> Should we skip 11 and go straight to 12, if a stable 12 version is
> available in time?
>
> I am a committer on the Solr project, but I wasn't involved in creating
> new SolrJ clients that use the Jetty client.  Every time I have tried to
> mess with upgrading jetty versions, I quickly get into problems that I
> cannot solve.
>
> I really suspect that the older 9.4.48 Jetty server is having problems
> that have been fixed in later versions ... and that it is possible that
> it's a problem created by how Solr uses Jetty.  I don't have the
> knowledge required to look deeper into it.  I gathered that debug log
> that I included earlier in the thread, but don't know what to look for,
> and don't know whether it even has what's needed to troubleshoot.
>
> I do not know how much of Solr's code is generic webapp and how much is
> specific to Jetty.  We ditched the notion of a generic .war file or
> extracted webapp quite a while back, and only support running Solr in
> the included scripting which uses Jetty.
>
> Thanks,
> Shawn
> _______________________________________________
> jetty-users mailing list
> [email protected]
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
_______________________________________________
jetty-users mailing list
[email protected]
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Reply via email to