контекст исполнения и будущее сцепление в игровой среде - PullRequest
Новая
       25

контекст исполнения и будущее сцепление в игровой среде

0 голосов
/ 29 августа 2018

Я пытаюсь решить конкретную проблему, в которой я должен достичь целей - 1) существует процесс, частями которого являются проверка, математическое вычисление и отправка сообщения, математическое вычисление необходимо выполнять только в случае успешной проверки, и аналогично сообщение следует отправлять только после завершения математического вычисления. 2) но я не могу написать здесь код блокировки, так как этот процесс занимает достаточно много времени, поэтому я использую разные контексты выполнения для каждого процесса и в будущем создаю цепочку

Таким образом, я определил разные пулы потоков для каждого процесса в application.config 

contexts {
  simple-db-lookups {
    executor = "thread-pool-executor"
    throughput = 1
    thread-pool-executor {
      fixed-pool-size = 20
    }
  }
  expensive-db-lookups {
    executor = "thread-pool-executor"
    throughput = 1
    thread-pool-executor {
      fixed-pool-size = 20
    }
  }
  db-write-operations {
    executor = "thread-pool-executor"
    throughput = 1
    thread-pool-executor {
      fixed-pool-size = 10
    }
  }

и через контроллер я звоню на фасад, который, в свою очередь, использует всеобъемлющий для как 

for{
result1 <- future1(call to validation)
result2 <- future2(result1) call to mathematical operation
} yield(result2)

Даже в вызове математической операции я использую такую ​​же конструкцию 

 future2(result1){

    result1 <- anotherMethodCallForMaths()
    result2 <- messagingCall(result1) //last future call
    }

anotherMethodCallForMaths{
implicit lazy val executionContext = <context for math op>
Future{
 logic
}(executionContext)
}

каждый из методов (messagingCall, anotherMethodCallForMaths и будущий вызов проверки) использует свой собственный контекст выполнения, так что никакие два задания не используют один и тот же пул потоков

Теперь, когда я проводил тестирование, из журналов ясно, что

будущий вызов проверки & anotherMethodCallForMaths правильно использует количество потоков, настроенных в пуле потоков, в то время как вызов обмена сообщениями использует правильный пул потоков, но не ограничен числом упомянутых потоков и использует / создает больше, чем настроенное число резьб.

Что может быть проблемой здесь, я пробовал разные ориентации, чтобы достичь того же, но сейчас ничего не получается.

...