lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Ramos Jardim <alexander.ramos.jar...@gmail.com>
Subject Snappuller opening too many threads
Date Sat, 09 Oct 2010 05:07:50 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message