Indeed, this exception put me on the wrong track, trying to figure out why the test was failing based on the exception, while I was "just" asserting the wrong property.
I now also understand what it is trying to tell me. And I must agree with Mike; given that the renderer is terminated, and it does no longer accept new jobs, there is no need to confuse coders and users with exceptions that neither have control over. Or can the coder do something to prevent these? Maybe allow for a way to hook into these exceptions with a callback / listener, or have them thrown via a command line setting, so if there is some kind issue they still can be tracked. On 4-8-2015 14:43, Mike Hearn wrote:
Race free shutdown in multi-threaded programs is always very hard. At Google some programs and libraries simply didn't support it: for servers, the cost in terms of bugs and extra code was deemed to outweigh the benefits, so the only "supported" way for a process to end was for it to be killed. JavaFX does not have that luxury. It must be able to shut down cleanly without races. In this case, the message is probably harmless: who cares if a render job doesn't complete if you're busy tearing down process state? So perhaps Quantum should just set a custom reject handler that ignores the issue instead of throwing. On Mon, Aug 3, 2015 at 4:10 PM, Tom Eugelink <t...@tbee.org <mailto:t...@tbee.org>> wrote: Working on a new skin for JFXtras Agenda... What is JavaFX trying to tell me with this exception? java.util.concurrent.RejectedExecutionException: Task com.sun.javafx.tk.quantum.PaintRenderJob@33cf88 rejected from com.sun.javafx.tk.quantum.QuantumRenderer@1133212[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 30] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) at com.sun.javafx.tk.quantum.QuantumRenderer.submitRenderJob(QuantumRenderer.java:218) at com.sun.javafx.tk.quantum.QuantumToolkit.addRenderJob(QuantumToolkit.java:467) at com.sun.javafx.tk.quantum.ViewScene.repaint(ViewScene.java:140) at com.sun.javafx.tk.quantum.PaintCollector.renderAll(PaintCollector.java:435) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:526) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:505) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$400(QuantumToolkit.java:334) at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/14510047.run(Unknown Source) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.lambda$null$145(WinApplication.java:101) at com.sun.glass.ui.win.WinApplication$$Lambda$43/19282349.run(Unknown Source) at java.lang.Thread.run(Thread.java:745)
