Fixing fastinputstream and javabin parsing may actually be as simple as
removing unsigned byte masks from the InputStream itself (some jetty fake
InputStream classes also unsign shift > 0 - the http client i InputStream
response handler for example - not sure if that would need to go) and
making su
There are lots of actionable items here from my view.
So many that I don’t see any general importance to any one of them on a
large scale.
I run into the same problem if someone where to say, let’s make sure all
the tests are solid for the upcoming release. Well what does that mean?
With little e
Anyway, returning the original sender:
I had not notice dist updates *are* using the http2 concurrent update
client now.
So that makes a lot of sense on why http 1.1 force improves things. It’s
not nearly as sensitive to connection management.
So I I’d still recommend sticking to http1, but one
FYI https://issues.apache.org/jira/browse/SOLR-15223 will deprecate Apache
HttpClient based SolrClients but I would hope that the Jetty HTTP Client
based SolrClients can be configured to use HTTP 1.1 if desired, although I
have not checked.
~ David Smiley
Apache Lucene/Solr Search Developer
http:/
On Wed, Jun 9, 2021 at 12:25 AM Mark Miller wrote:
>
> Instead of respecting stream contracts, JavaBin is given how much to read
> and it diligently works to read to that point or in some cases it’s own end
> marker.
>
>
That sounds actionable, should it be reading the available contents into an
Though I should say: while I won’t file some large general jira issue about
all the problems that can more visibly manifest in connection fails and
stalls when moving from the Apache client to the jetty client, from the old
SolrClient impl to the Http2 impl, from Http1.1 protocol to 2, how JavaBin
There is no line of code to point to.
I see in the stack trace now that SolrCmdDistributor was updated to the
http2 client.
Lots more stalls and exceptions seen unless that client is changed to use
http1 instead of 2.
But still a lesser problem remains with 1.1.
That is a bit of info on why thi
Mark, can you file a JIRA issue (if one doesn't already exist), ideally
pointing to a line of code that is problematic?
Do you think we should drop the "closeShield" stuff in SolrDispatchFilter?
Not sure if there is a test exercising the scenario that led to its
inclusion; I doubt it.
~ David Smi
A few details on how JavaBin can be involved in this type of behavior:
JavaBin consumes data by by wrapping InputStream’s with a FastInputStream.
FastInputStream implements an InputStream, but it disregards the
InputStream contract that says you have reached the end of the stream when
-1 is return
Given you say you saw a lot of this and that occurred after a specific
upgrade, I would guess your root issue is JavaBin.
Unfortunately, I don’t believe you can change internode communication to
another format if that’s the case.
But also if that is the case, it will be in the way of some work I
You can run into this fairly easily even if you are doing everything right
and none of your operations are intrinsically slow or problematic.
DeleteByQuery, regardless of its cost, tends to be a large contributor,
though not always. You can mitigate a bit with cautious, controlled use of
it.
I’m
Hi,
This message indicates that the SolrJ ConcurrentUpdateHtp2SolrClient detected
that an update request was taking excessive time to process without making any
progress. In such situations the client will eventually abort the update in
order to avoid getting completely stuck with a full buffer
Background:
Before we moving to solr 8.8.1 from 7.7.2, we performed some performance test
on solr 8.8.1. We met a lot of concurrent update error in solr log.
Envrironment:
solrCloud with 3 cluster nodes with 500 collections, 5 collections have about
10m documents.
(1 shard, 3 replica)
Threads:
30
13 matches
Mail list logo
