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