javafx.concurrent.Service uses internally a java.util.concurrent.ExecutorService to execute its Tasks. Instances of ExecutorService need to be shut down after usage. This does not seem to be the case for javafx.concurrent.Service. How and when does javafx.concurrent.Service shutdown its ExecutorService ?
I think your misunderstanding here comes from:
Instances of ExecutorService need to be shut down after usage.
Calling shutdown() prevents an ExecutorService from accepting new tasks. You only need to do that if it makes sense to do so (e.g. you are trying to exit the application and want to make sure that any new tasks submitted during application exit are ignored. This might happen with a scheduled executor service, for example).
The related shutdownNow() will additionally attempt to interrupt any currently running threads. So if your tasks are implemented to accept interrupts gracefully, calling shutdownNow() gives those tasks the opportunity to perform any cleanup operations necessary (closing connections, etc).
In many use cases, however, there is no need to call either of these methods. If you are assured no further tasks will be submitted to the executor, shutdown() is unnecessary. If your tasks are not long-running, shutdownNow() is unnecessary. When the application attempts to exit, any existing tasks will complete (presumably reasonably quickly) and then the application can exit.
Note that if your executor service uses daemon threads, then when the application attempts to exit, those threads will not prevent application exit (they will be terminated, without interruption). So if your tasks are short-lived, require no cleanup, and can be safely terminated at any point, this is a viable strategy.
There is nothing special about javafx.concurrent.Service here: in some sense it is a wrapper for an ExecutorService that provides additional functionality for interacting with the FX Application Thread. Just note that the default executor service provided uses daemon threads, so as above, if your tasks need cleanup you would likely provide a different executor service and shut it down gracefully in the application's stop() method.
Related
from what I can comprehend briefly, both of them processing flow asynchronously with VM scope using more resource as it create new context, separate properties and variables. Any particular reason other than that if the use is just to process the flow asynchronously?
Async is a scope that is executed immediately in parallel with respect to the flow, if there are resources available (ie threads). VM is a connector that implements an in-memory queue. I usually recommend to prefer to use the VM connector because with Async if there are no threads available it can fail to execute. With the VM connector the messages will be queued until the flow that reads from the VM queue is able to read the next message. Note that if the number of messages queued is greater than the number of messages processed it will run out of memory or exceed the queue allocation, causing another error.
Always remember that threads are a limited resource. In Mule it is not possible to control the number of threads used, only the concurrency. Also keep in mind that threads are not free, they consume memory and CPU.
This is a design question about the handling of tasks during the shutdown of a firebase-queue based app running on Google Compute Engine.
The use case I am working with is automatically scaling queue-workers depending on the load at any given time. Specific to our project is the fact that our tasks are long-running.
In an ideal world, the queue worker would have an opportunity to finish its current tasks before the virtual machine running the worker is terminated. We are working with Google Compute Engine / instance groups to handle the scaling of our queue worker app. Firebase-queue does provide a promise based method to shutdown a queue worker (i.e. queue.shutdown()). This will stop the worker from accepting new tasks and will allow running tasks to finish prior to resolving the promise.
The problem I am facing is how to allow the queue worker to shutdown gracefully prior to instance termination (this problem would also occur during a rolling update). One way is to trigger the worker shutdown and have the worker trigger instance shutdown, but this does not seem like the best design because control is taken away from whatever service is triggering the scale down in the first place.
GCE does provide a service which will run a shutdown script prior to instance termination, however, it will forcefully shutdown an instance after about 90 seconds, which does not work for us.
I am interested in design ideas / patterns to follow here. Any help is much appreciated.
I can't seem to find this specific implementation detail, or even a pointer to where in an OS book to find this.
Basically, main thread calls an async task (to be run later) on itself. So... when does it run?
Does it wait for the run loop to finish? Or does it just randomly interrupt the run-loop in the middle of any function?
I understand the registers will be the same (unless separate thread), but not really the instruction pointer and what happens to the stack, if anything does happen.
Thank you
In C# the task is scheduled to be run on the current SynchronizationContext. The context basically has a queue of tasks which it schedules to run on the threads it is associated with, in a GUI app there is only one thread so the task is scheduled to run there.
The GUI thread is not interrupted but it executes the task when it finishes all other tasks preceding it in the queue.
The threads of a process all share the same address space, not the same CPU registers. The thread scheduling is done depends on the programming language and the O/S. Usually there are explicit scheduling points, such as returning from a system call, blocking awaiting I/O completion, or between p-code instructions for interpreted languages. Some O/S implemtations reschedule depending on how long a thread has run for time-based scheduling. Often languages include a function that explicitly offers the CPU to any other thread or process by transferring control to the process or thread scheduler component of the O/S.
The act of switching from one thread or process to another is known as a context switch and is carefully tuned code because this is often done thousands of times per second. This can make the code difficult to follow.
The best explanation of this I've ever seen is http://www.amazon.com/The-Design-UNIX-Operating-System/dp/0132017997 classic.
I have used Quartz.Net for queuing and sending emails from my application. I don't know how each scheduled job responds to application instance stopping, pausing or shutting down. The IJob interface has no method that can notify a running job about these events.
My question is how can I handle these cases when they occur so that the job can exit while leaving the application and the data in a stable state?
Make sure you call IScheduler.Shutdown(true) when your application shuts down. This will wait for all jobs to finish and ensure everything is cleaned up correctly.
we have a scenario where in whil serving one asp.net request from iis from our code we have created a child thread from thread pool to servve some background task.the idea was to finsih the main thread wihich is processing the request without depending on our child thread task. But our doubt is while processing a request in asp.net will workerprocess wiat untill the thread finishes its task ?
No, if you've created a separate thread and don't have any code to wait on it, the request will certainly complete.
What I don't know is whether a worker process can be recycled while there are non-ASP.NET thread pool threads executing. I strongly suspect it can - so be aware that your child task could be terminated at any point. If this is a problem, you may wish to create a non-threadpool foreground thread.
No, the background thread will not wait for the main thread to finish, it will start immediately. If you use the Thread pool your task may have to wait for a thread to be available, but that is all.
You should however be aware that this may not be a good solution, for the application domain your asp.net site is running in may be recycled while your background thread is running. This will kill the background thread leaving the task incomplete. If it is possible, you should separate the background task into a service application that runs in a separate process. This will ensure that the task isn't killed while running.