[jira] [Created] (AURORA-100) Thrift connection appears to keep the scheduler from shutting down

["Bill Farner (JIRA)" <ji...@apache.org>]

Bill Farner created AURORA-100:
----------------------------------

             Summary: Thrift connection appears to keep the scheduler from shutting down
                 Key: AURORA-100
                 URL: https://issues.apache.org/jira/browse/AURORA-100
             Project: Aurora
          Issue Type: Bug
          Components: Scheduler
            Reporter: Bill Farner
            Priority: Minor


This originally cropped up when we were using thrift 0.5.0, so the code sample below will be stale:

Looking at TThreadPoolServer source, the behavior here makes sense. We use the default ExecutorService created by TThreadPoolServer, which uses non-daemon threads. Here's TThreadPoolServer's serve loop:
{code}
  public void serve() {
    try {
      serverTransport_.listen();
    } catch (TTransportException ttx) {
      LOGGER.error("Error occurred during listening.", ttx);
      return;
    }

    // Run the preServe event
    if (eventHandler_ != null) {
      eventHandler_.preServe();
    }

    stopped_ = false;
    setServing(true);
    while (!stopped_) {
      int failureCount = 0;
      try {
        TTransport client = serverTransport_.accept();
        WorkerProcess wp = new WorkerProcess(client);
        executorService_.execute(wp);
      } catch (TTransportException ttx) {
        if (!stopped_) {
          ++failureCount;
          LOGGER.warn("Transport error occurred during acceptance of message.", ttx);
        }
      }
    }

    executorService_.shutdown();

    // Loop until awaitTermination finally does return without a interrupted
    // exception. If we don't do this, then we'll shut down prematurely. We want
    // to let the executorService clear it's task queue, closing client sockets
    // appropriately.
    long timeoutMS = stopTimeoutUnit.toMillis(stopTimeoutVal);
    long now = System.currentTimeMillis();
    while (timeoutMS >= 0) {
      try {
        executorService_.awaitTermination(timeoutMS, TimeUnit.MILLISECONDS);
        break;
      } catch (InterruptedException ix) {
        long newnow = System.currentTimeMillis();
        timeoutMS -= (newnow - now);
        now = newnow;
      }
    }
    setServing(false);
  }
{code}
The important bit, near the end, is that they never invoke executorService_.shutdownNow , which would terminate active connections.
This is likely a deliberate design choice, and thrift 0.6.0+ allows callers to provide their own ExecutorService, which would give us some more control here.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)