Probably a topic for dev@ mailing list ;-). Would be great to convert this into a test to demonstrate the problem. I’m very interested in getting us to Http2, and I think we need a way to get more “real world integration testing” done ;-).
> On Dec 21, 2022, at 5:55 AM, Shawn Heisey <apa...@elyograg.org> wrote: > > I was attempting to use Http2SolrClient in a simple test application. I am > using SolrJ 9.1.0 pulled as a dependency with Gradle. > > https://paste.elyograg.org/view/f9bbe53c > > Solr is 9.2.0-SNAPSHOT, behind a TLS-enabled proxy. Solr itself is running > in cloud mode on port 8983 without TLS, the proxy makes it available via > https on port 443. The proxy supports all versions of HTTP. > > In the code linked, if I comment the usage of Http2SolrClient, uncomment the > usage of HttpSolrClient, and fix the imports, everything works. > > I couldn't get Http2SolrClient to work at all without giving it an SSLConfig > object. Jetty HttpClient throws NPE saying it does not have > SslContextFactory. With HttpSolrClient I don't have to do anything with SSL > config, it just works. > > If I don't add "sc.close();" when using Http2SolrClient then the program > never exits. I imagine a try-with-resources would also work. I do realize > that proper cleanup in a long-running program requires using close, but if > the program ends, I would think that should work with or without doing proper > cleanup. > > I think this must mean that Jetty HttpClient is starting "normal" threads > rather than daemon threads, and this might be something I need to discuss > with the Jetty project, but I thought I would ask here first. > > Thanks, > Shawn _______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
