Say I start a thread(not daemon) of my own in a servlet(can be a controller in springMVC app or a struts action controller):
Let us assume that the action is done with it's processing and wants to push the response out. Will this happen even though the thread I started is still running? Basically what I want to know is will the container wait till the thread is done with it's work to push the response out?
Assuming in the above, the container does not wait for the thread to push response out, will it wait till the background thread is done to reap the servlet thread spawned to handle this particular request or it will reap this thread only when the custom thread is done with it's work?
A custom thread spawned by a servlet thread is no different than any other thread: it's an independant, parallel flow of execution. The servlet thread doesn't care about the custom spawned thread: it continues its execution.
So the response will be sent to the browser as if no custom thread had been spawned, and whether the custom spawned thread is still running or not is irrelevant.
Once the servlet thread has finished serving the request and sending the response, it goes back to the pool and can start serving another request. Once again, whether a custom thread has been spawned, and whether this custom thread is still running, are irrelevant.
Related
I'm using ServiceStack MQ (ServiceStack.Aws.Sqs.SqsMqServer v4.0.54).
I'm running MQ server inside a Windows Service.
My Goal:
When the Windows service is about to shutdown, I would like to
wait for all running workers to finish processing and then terminate
the MqServer.
Problem:
The ServiceStack MqServer (whether it's Redis/RabbitMq/Sqs) has a Stop() method. But it does not block until all workers complete their work. It merely
pulses the background thread to stop the workers and then it returns.
Then the Windows Service process stops, and existing workers get aborted.
This is the link to github source code -> https://github.com/ServiceStack/ServiceStack/blob/75847c737f9c0cd9f5dd4ea3ae1113dace56cbf2/src/ServiceStack.RabbitMq/RabbitMqServer.cs#L451
Temporary Workaround:
I subclass SqsMqServer, loop through the protected member 'workers' in the base class, and call Stop on each one. (in this case, this Stop() method is implemented correctly as a blocking call. It waits indefinitely until the worker is done with whatever it's currently working on).
Is my current understanding of how to shutdown the MqServer correct? Is this a bug or something I misunderstood.
The source code for SqsMqServer is maintained in the ServiceStack.Aws repository.
The Stop() method pulses the bg thread which StopWorkerThreads() and that goes through and stops all workers.
I have a spring controller. The request thread from the controller is passed to the #Service annotated Service class. Now I want to do some background work and the request thread must some how trigger the background thread and continue with it's own work and should not wait for the background thread to complete.
My first question : is this safe to do this.?
Second question : how to do this.?
Is this safe
Not really. If you have many concurrent users, you'll spawn a thread for everyone of them, and the high number of threads could bring your server to its knees. The app server uses a pool of threads, precisely to avoid this problem.
How to do this
I would do this by using the asynchronous capabilities of Spring. Call a service method annotated with #Async, and the service method will be executed by another thread, from a configurable pool.
I ran into an interesting problem in IIS and I would like to get to the bottom of it.
I have an app that long polls . i have implemented my own long polling.
A request comes in. I block that req and write to it from my worker thread.
then everything finish. I signal. And the thread that was handling the GET request is releases.
I am not talking about scalability here. It is not my concern.
Just for testing, I ONLY make concurrent get requests.
So there is only 2 threads running. ONE for the get request and one worker thread.
I know that Request threads exits safely.I put a print right before the Action of the Controller returns. (Is that good enough?)
what I run into is. IIS slows down after a while even though I am exiting the GET thread.
So why is it slowing down ? When I implemented with AsyncController it does not slow down.
I know AsyncControllers attach and detach the threads from the pool. But if I have 25 thread available in my pool and If I have one active thread for worker and one thread that enters and exits for the get. I am sort of lost. Thanks
Situation: A high-scale Azure IIS7 application, which must do this:
Receive request
Place request payload onto a queue for decoupled asynchronous processing
Maintain connection to client
Wait for a notification that the asynchronous process has completed
Respond to client
Note that these will be long-running processes (30 seconds to 5 minutes).
If we employ Monitor.Wait(...) here, waiting for a callback to the same web application, from the asynchronous process, to invoke Monitor.Pulse(...) on the object we invoked Monitor.Wait() on, will this effectively create thread starvation in a hurry?
If so, how can this be mitigated? Is there a better pattern to employ here for awaiting the callback? For example, could we place the Response object into a thread-safe dictionary, and then somehow yield, and let the callback code lock the Response and proceed to respond to the client? If so, how?
Also, what if the asynchronous process dies, and never invokes the callback, thus never causing Monitor.Pulse() to fire? Is our thread hung now?
Given the requirement you have, I would suggest to have a look at AsyncPage/AsyncController (depends on whether you use ASP.NET WebForms or ASP.NET MVC). These give you the possibility to execute long running tasks in IIS without blocking I/O threads.
I have inherited a set of legacy webservices (VB.Net, IIS hosted ASMX) in which some of the WebMethods are using basic multithreading.
It seems like they have done this to allow the WebMethod to return to the client quicker with a response, while still doing some longer running operations that do not impact the response object itself (such as cleanup operations, logging, etc).
My question is, what happens in this webservice when the main thread (that which created the WebMethod instance) completes? Do these other threads terminate or does it actually block the main thread from completing if the other threads are not complete? Or, do the threads run to completion on the IIS process?
Threads are independent of each other unless one thread waits on another. Once created, there is nothing stopping the request (main) thread from completing, and any other threads simply complete on their own.