I have a long running process in WCF that takes 2-3 hours. The WCF runs for a long time after essentially the client that started the process leaves/times out. How long does it take for a WCF w3wp process to disappear since there was no connections to it. I'm thinking that even though the WCF is processing, it might stop WCF service because there was no new connection to it?
IIS will wait for the service operation to complete plus the idle timeout minutes and then shut down the app pool. The default idle timeout is 20 minutes.
Related
Threads on a multi threaded windows service (aka serviceA) want to wait for RabbitMQ to become available. RabbitMQ may be turned on or off at any point in time while serviceA is running. What is the best way to wait for RabbitMQ to become available?
Should each thread set a timer for an interval - when the timer has elapsed, check to see if it can connect again?
A while loop would be processor intensive.
Thread.Sleep() can prevent the Windows service from stopping.
Thread.SpinWait() seems to be CPU intensive.
In addition, what if:
RabbitMQ service is stopped
serviceA is then started
10 minutes later, or 3 days later, RabbitMQ service is started
how about register callback with task and use async method from RabbitMQ Client, i understand Rabbit support asynchronous message handler using AsyncEventingBasicConsumer
you can check on Handle RabbitMQ in async way
I have developed a WCF service for serving our customers and hosted it on IIS. We have a requirement to log all the requests received and responses sent from WCF in to a database.
But, because of this logging, we don't want to interrupt main flow of requests and responses. So, we are using threads (Threading.Thread and Thread.IsBackground = true) to call procedures to insert/log the requests and responses to database.
I just want to know if there will be problems in implementing/invoking threads on a WCF service. If so, what will be a good solution for this?
Yes, there can be a problem. The application pool in IIS can get recycled which means that the background thread will be killed, even if it's in the middle of some processing.
In reality that will only be a problem when you update your application (as the logger should be done when the app pool is stopped due to the idle timeout).
So if you can live with lost log entries during updates you do not have a problem.
I implemented a WCF service that will do some long task. It needs to provide client with notifications about current progress of that long task. It is working well so far, but the problem is:
When user closes the client app, and then open it again, client app should start receiving updates from server again about the task that is running.
There can be multiple tasks started by different users at the same time.
So for example, client starts a process named "proc1" that will be 3 hours long, and after 15 minutes he closes the app. The process continues to work on server. After 30 minutes client starts the app again and then client app needs to start getting notifications about the process client has started 30 minutes ago. How can this be accomplished?
Thanks in advance.
You should save on client side some process id that can be used later to get progress of that process. Try using that process id to reconnect to the notifications.
In my application, i've set the openTimeOut to 1 minute. Now if the service is stopped or server is not running then it causes the problem.
I need to load the forms on the basis of output from the service. I call the service while loading the content of the form. Now if the server is stopped it will hang the UI till the openTimeOut of the service. Main issue is , application uses multiple services and for some other service the timeout is 35 seconds and if it timeouts then it is re-starting the application and my service is still in the openTimeOut mode which results in crashing of the application.
What could be the best solution for this problem.
My question is what is the best way to handle this condition - reduce the openTimeOut or call the service on different thread.
Definitely call the service on a different thread (or, if you use an auto-generated service proxy, you can switch Async versions of the methods which amounts to the same thing). The UI thread should not be dependent on long-running operations or those that may block.
The value of OpenTimeOut will not significant as far as hanging the app (because that will stop happening), but you may want to lower it a bit because 1 minute is perhaps too long to wait in order to discover that no connectivity to the service exists.
There is a WCF Service with a long-running Asynchronous Thread.
This long-running operation can run more then 1 day.
We are hosting WCF Service on IIS 6.
The Thread is running OK, but in 20 minutes we are receiving error message:
"Thread has been aborted"
The Thread is dead as a result.
Our WCF Service configuration:
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
Can you suggest the source of this problem?
Thank you for you answers.
If there's no activity (no requests) to this web service IIS might decide to unload the application domain which of course will result in killing all threads. The default value is 20 minutes and could be configured in the properties of the application pool in IIS. There are also other factors that might cause the app pool to be recycled such as system running on low memory. So hosting such thing in IIS might not be reliable. You might consider hosting long running tasks in Windows Services.
IIS6 has a setting that will shut down the app pool after a predefined time with no requests, the default is 20 minutes. It seems like that is what you are running into. You can find this setting under App Pool properties => Performance Tab => Remove checkmark in "Shutdown worker processes after being idle for".
In general, it is considered a bad idea to host long-running tasks under IIS, since there are many things that may abort the thread or shutdown the process altogether. Application Pool recycles being the most prominent one.
You could have a Windows Service host a WCF endpoint that kicks off your long running task. Windows Services are meant to be running a long, long time and are ideal for this situation.