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 of using Solr's DefaultSolrThreadFactory which names threads with a proper prefix, I used Java's DefaultThreadFactory which names threads like pool-123-thread-1282. So if you take a thread dump from Solr 6.6, you should be able to find threads named like these which are sleeping at a similar place in the stack. On Tue, Oct 23, 2018 at 9:14 AM Clemens Wyss DEV <clemens...@mysign.ch> 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)! > > > autoCommit is quite long. I'd probably go with 60 seconds > Which means every 1min the "pending"/"soft" commits are effectively saved? > > One additional question: having auto(soft)commits in place, do I at all > need to explicitly commit UpdateRequest from SolrJ? > > > added in 5.5.3 and 6.2.0 by this issue > hmmm, I have never seen these threads before, not even in 6.6 > > > Shalin worked on that issue, maybe they can shed some light on it and > >indicate whether there should be many threads running that code > I'd appreciate > > Yet again, many thanks. > - Clemens > > -- Regards, Shalin Shekhar Mangar.
