Заказ будущего звонка и Пользовательский Исполнитель - PullRequest
Новая
       24

Заказ будущего звонка и Пользовательский Исполнитель

1 голос
/ 03 апреля 2020

Я сталкиваюсь с проблемой, когда исполнитель не закрывается, а второй последний будущий вызов выполняется после последнего будущего вызова, и программа не завершается. 


  import java.util.concurrent.Executors

  import scala.concurrent.ExecutionContext

  val customExecutor: ExecutorService =
    Executors.newFixedThreadPool(serviceConfig.serviceConf.numberOfThreads)
  implicit val customExecutionContext: ExecutionContext =
    ExecutionContext.fromExecutor(Executors.newFixedThreadPool(10))

  val remainingRecords = data.foldLeft(Seq.empty[Int]) {
    case (a, b) =>
      fetchAllData()
        .foldLeft(c) {
          case (a, file) =>
            sendInBatches(a)
        }
  }

  @scala.annotation.tailrec
  def sendData(res: Seq[Int]) = {
    ...
    futureCall() map { result =>
      logger.info(
        s"Successfully Executed"
      )
    }
    sendData()
  }

  if (remainingRecords.nonEmpty) {
    futureCall() map { result =>
      logger.info(
        s"Successfully executed the remaining"
      )
      customExecutor.shutdown()
    }
  }

Я получаю журнал "Успешно выполнил оставшиеся "затем" успешно выполнены ", и приложение не остановилось, даже когда я вручную выключил исполнителя.

1 Ответ

0 голосов
/ 04 апреля 2020

Это длинный выстрел, но этот код: 

def sendData(res: Seq[Int]) =
    {
        ...
      futureCall() map { result =>
      logger.info(
      s"Successfully Executed"
      )
    }
      sendData()
    }

НИКОГДА не заканчивается. executor.shutdown() предотвращает планирование новых задач в пуле потоков, но не убивает текущие задачи, чтобы обеспечить постепенное завершение работы. Поскольку этот код выполняется, а задача никогда не заканчивается, исполнитель ожидает его завершения до 1010 * и ждет и ждет ...

Вы можете попробовать использовать shutdownNow() и / или сделать это эффективно бесконечно l oop до конца, если вы обработали все данные, добавив некоторую проверку перед рекурсивным вызовом sendData().

...