You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Alexander Ramos Jardim <al...@gmail.com> on 2010/10/09 07:07:50 UTC
Snappuller opening too many threads
Hi there people,
I was running my Solr aplication in one server and the client application in
other one. So far so good.
I wanted to make some benchmarks between embedded and http access. So I put
one Solr instance in the same server my application is running. Again, so
far so, good. I made my benchmarks.
But one thing became clear to me when I ran Solr in the same server with the
application. The threads it opens to execute the Snappuller, don't get
finished. They stay there for a lot of time, or simply don't finish.
The stack trace of these threads was always the same. Something about the
concurrent util package (Didn't take the thread dump properly).
So, I began to searching in the Solr code and I found it:
private void startExecutorService() {
Runnable task = new Runnable() {
public void run() {
if (pollDisabled.get()) {
LOG.info("Poll disabled");
return;
}
try {
executorStartTime = System.currentTimeMillis();
replicationHandler.doFetch(null);
} catch (Exception e) {
LOG.error("Exception in fetching index", e);
}
}
};
executorService = Executors.newSingleThreadScheduledExecutor();
long initialDelay = pollInterval - (System.currentTimeMillis() %
> pollInterval);
executorService.scheduleAtFixedRate(task, initialDelay, pollInterval,
> TimeUnit.MILLISECONDS);
LOG.info("Poll Scheduled at an interval of " + pollInterval + "ms");
}
I know the problem is not there, but in the fact that the threads opened to
snappulling are not finished at all. Is there a way to put some work manager
to take care of these threads? Is there any plan to correct this behavior?
--
Alexander Ramos Jardim