Scala 선물을 사용할 때 RejectedExecutionException을 잡는 방법?

Question

Executor를 종료 할 때 어디에서 RejectedExecutionExceptions를 잡아야합니까? 나는 시도 :

future { 
     Option(reader.readLine) 
     } onComplete { 
     case Success(v) => 
     case Failure(e) => e match { 
      case ree: RejectedExecutionException => 
      // doesn't work 
     } 

과 :

try { 
     future { 
      Option(reader.readLine) 
     } onComplete { 
      ... 
     } 
     } catch { 
     case ree: RejectedExecutionException => 
      // doesn't work 
     } 

도 작동하지 않습니다. 여전히 받고 :

Exception in thread "pool-99-thread-1" java.util.concurrent.RejectedExecutionException 
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768) 
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767) 
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658) 
at scala.concurrent.impl.ExecutionContextImpl.execute(ExecutionContextImpl.scala:105) 
at scala.concurrent.impl.CallbackRunnable.executeWithValue(Promise.scala:37) 
at scala.concurrent.impl.Promise$DefaultPromise.tryComplete(Promise.scala:133) 
at scala.concurrent.Promise$class.complete(Promise.scala:55) 
at scala.concurrent.impl.Promise$DefaultPromise.complete(Promise.scala:58) 
at scala.concurrent.impl.Future$PromiseCompletingRunnable.run(Future.scala:23) 
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) 
at java.lang.Thread.run(Thread.java:662) 

Answer 1

그것은 RejectedExecutionHandler에 의해 처리되어야합니다. java.util.concurrent.ThreadPoolExecutor.DiscardPolicy 또는 맞춤 구현.

이 실행자는 자동으로 RejectedExecutionException 통과 :

val executorService = new ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue[Runnable], Executors.defaultThreadFactory, new DiscardPolicy) 

Answer 2

내가 그 in this thread에 대해 물었다.

동일한 실행 프로그램에서 실행중인 경우 현재 등록 된 콜백이 시스템 종료시 완료되어야한다고 느꼈습니다. (또는 행동은 정책에 의해 관리되어야합니다.) (언젠가는 설명했듯이 PR을 제출할 것입니다.)

이전에 단일 스레드 실행 프로그램이 일부 파일을 읽었으며 작업을 다른 풀로 보냈습니다. 초기 설계는 피더가 제출시 차단하여 스스로를 조절할 수 있도록 설계되었습니다. 괜찮 았지만 융통성이 없었습니다. 두 번째 풀에서 몇 가지 작업을 포크하고 싶었지만 제출은 차단되었습니다.

차단이 악의적 인 경우 작업을 실행할 수 없다는 것을 알고 나면 작업을 수행해야 할 대상을 결정해야합니다.

하나의 대답은 종료를 시작하기 전에 대기를 기다리는 것입니다. 제 경우에는 일자리 수가 많아서 일이 언제 끝났는지 알았습니다.

빅토르 클랭 (Viktor Klang)은 스레드가 항상 작업을 포크하고 항상 제출한다는 점을 알고 있었기 때문에 정지가 무엇인지 아는 사람이라면 인프라가 아니라 앱입니다.