What launches the Connection evictor thread and what can be done to avoid these threads to accumulate?

Viewed 1508

My Java program runs under linux and indexes several directories (that are mounted via samba from different windows servers) with SOLR 7.4. It updates the different indexes (one index per indexed directory) one after the other and loops back infinitely.

While running on my dev machine I attached VisualVM to it and saw that the number of threads keeps increasing :

VisualVM shows increasing number of threads

I understand from this post that it has something to do with memory leak (that I am also trying to find).

VisualVM shows that Connection evictor threads keep accumulating and are all in sleeping state :

Sleepling connection evictor threads accumulate

But this post tells that sleeping threads won't add any load to the system (because they are idle), so they will not cause memory leak.

So my questions are :

Should I consider this behaviour as a problem, and if so where should I look at in the source code since I don't use http connection (which I read uses connection evictor) as all directories are locally mounted by the OS ?

Any help appreciated ;-)

1 Answers

To answer my own question briefly :

Yes having so many Connection Eviction threads is a problem on production since I assume it caused an OOM after a while.

For me the problem occured because I created too many SolrClients whereas a single one was needed (all the cores are on the same server).

So instead of

solrClient = new HttpSolrClient.Builder(
                getSolrHomePath() + "/" + getCoreName()
        ).
                build();

where getSolrHomePath() returns the path to solr-X.Y.Z/server/solr.

I now use

commonSolrClient = new HttpSolrClient.Builder(
                getSolrHomePath() 
        ).
                build();

and when I need to query a core I pass the core name as first parameter to the query function. Same for add/delete methods!

Related