> read from the streams in parallel and put the tuples on a bounded > queue, and then read from that with a single thread. You just have to avoid > a single thread doing the reads sequentially.
I am still thinking through this but one thing to remember is that SolrCloudStream's ordering guarantee. In effect, this means that as long as all shard's still have tuples to contribute you must ensure that your in-memory queue has at least one tuple from each shard in it before it can return next. So if your consuming thread depletes shard N's tuples completely it must wait for that shard to send its next tuple before it knows for sure what the next tuple should be. So I am not sure this actually solves the problem? (Because what if the session window is completely occupied by non-shard-N responses and the application queue is full?). I can see how this could perhaps mitigate the issue because you could make this queue much bigger for this specific application. This is better than making the http/2 session window bigger which could have unintended side effects since it is such a global setting. Luke From: [email protected] At: 02/19/26 20:12:30 UTC-5:00To: [email protected] Subject: Re: HTTP/2 Struggles With Large Responses That’s a nice investigation. You can get around the streaming “cannibalism” issue by doing something like: read from the streams in parallel and put the tuples on a bounded queue, and then read from that with a single thread. You just have to avoid a single thread doing the reads sequentially. But that just puts the streaming situation into the replication issue - meaning performance problems. So moving to that issue. From what I’ve read, HTTP/2 can be just as fast as HTTP/1 for these large stream cases. The main issue that tends to cause the stall performance problems is the client not reading fast enough to keep up with the server. But that will cause stalls in HTTP/1 as well. I’ve also read, that outside of that issue, HTTP/2 performance for this can match HTTP/1 by configuring the client receive window using a formula based on the bandwidth-delay-product (based on network bandwidth and latency.) Well, that’s a lot less than ideal. These two use cases should just explicitly use HTTP/1. - MRM
