e ForkJoinPool.commonPool-worker's, but 27 is not >90
Thx
- Clemens
(*) I will follow Shawn's advices in this thread asap
-Ursprüngliche Nachricht-
Von: Shalin Shekhar Mangar
Gesendet: Dienstag, 23. Oktober 2018 10:30
An: solr-user@lucene.apache.org
Betreff: Re: AW: AW: 6.6 -> 7.5
On 10/22/2018 9:44 PM, Clemens Wyss DEV wrote:
On 10/22/2018 6:15 AM, Shawn Heisey wrote:
autoSoftCommit is pretty aggressive . If your commits are taking 1-2 seconds or
les
well, some take minutes (re-index)!
Are you absolutely sure that you have commits taking that much time?
I'm not
You can expect as many connection evictor threads as the number of http
client instances. This is true for both Solr 6.6 and 7.x.
I was intrigued as to why you were not seeing the same threads in both
versions. It turns out that I made a mistake in the patch I committed in
SOLR-9290 where instead
On 10/22/2018 6:15 AM, Shawn Heisey wrote:
> autoSoftCommit is pretty aggressive . If your commits are taking 1-2 seconds
> or les
well, some take minutes (re-index)!
> autoCommit is quite long. I'd probably go with 60 seconds
Which means every 1min the "pending"/"soft" commits are effectively
On 10/21/2018 11:10 PM, Clemens Wyss DEV wrote:
For the UpdateRequests it is the "commitWithinMs"-parameter? To me
this parameter sounds like telling the solr-server I need to see this
data within "x ms". As we have autoCommit and autoSoftCommit
The commitWithin parameter is effectively
On 10/21/2018 01:06 PM, Shawn Heisey wrote:
> You do it with the request, not with the client
For the UpdateRequests it is the "commitWithinMs"-parameter? To me this
parameter sounds like telling the solr-server I need to see this data within "x
ms". As we have autoCommit and autoSoftCommit
...
