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.
Related
I have a ASP.NET WEB API application hosted on IIS. IIS is queuing request. The server is not very busy and I still get queuing. So I am trying to find out the reasons IIS would queue requests. The main reason (only) I have heard is if the max threads is reached. I suspect it is something I am doing in my application but I have no idea what that could be. Does anyone know IIS well enough to tell me the reasons requests get put into the request queue or point me in the proper direction?
Is there any way to get hold of current active threads in IIS or list of blocked threads in IIS. is there any tool that can help us with this. I checked the event viewer and it was clean.
Is it a good idea to initialize a timer to do a periodic task in a WCF service host or will that mess with the lifecycle or performance of the service being hosted?
I have a custom service host that announces it's availability (with the goal of creating a registry for clients) upon starting and stopping. I want to create a timer to do this periodically but my concern is that this will cause problems (I haven't ran into any yet but maybe I haven't stressed it enough or something) or maybe it will eat resources and kill the performance of the service. The idea is to hookup the timer on the OnOpened and OnClosing events, of course.
For what is worth, this service is hosted in IIS so it is IIS the one instantiating and managing the service host.
Is it a good idea to initialize a timer to do a periodic task in a WCF
service host or will that mess with the lifecycle or performance of
the service being hosted?
That will depend on where your WCF service is hosted. If it is hosted inside IIS it might be problematic. The reason for this is because IIS can decide to recycle the ASP.NET application pool at any time and your timer will simply stop working. It is not something you can rely upon. If on the other hand you have hosted your WCF service inside a Windows Service self host, it is fine to use a timer. You may take a look at the following blog post about the dangers of implementing recurring background tasks in ASP.NET hosts.
I have some legacy ASMX IIS hosted service. Client applications make subscribe or unsubscribe to the web service. Via some internal to the web service logic it needs to send messages to the subscribed applications periodically.
What is the best way to do the part of the long running task ? I understand opening Thread with long running task not a good idea to do under IIS.
ASMX services cannot do what you're asking for: they cannot just decide to send a message to the client. All they can do is respond if the client requests it.
You can hack around and come up with one method to start the long-running task, and another method to poll for the status of the task. This works, but it can be expensive.
The better model is to perform the long-running task in a separate Windows Service. Have that service host a simple WCF service which will only be used by the main service (the one that talks to the clients). The main (WCF) service would use a Duplex channel to communicate with the clients. That way, it can "call" the clients whenever there is news about one of the long-running tasks.
Usually in such cases when you don't have a way to push the result back, create an unique ID for the long running task and sent it back to the client, after that run the task and have a table in database or something else where you store the status of the task. The client will pull periodically the service to see the task' status by given ID. Once it finds the task is completed it will retrieve the result.
And is completely fine to have a thread running inside IIS doing its job.
I am building a WCF service that will expose several operations, it will run in IIS because it needs HTTPS endpoints. Most of the operations will perform within seconds or less; however, one or two of these operations will take between 5-90 minutes.
The primary consumer of this service will be an ASP.NET MVC application; what is the correct way to do handle this?
Should I jackup the timeout and do some ajax calls? Should I add a table to my database, and have the long running operations update this database, and have the web interface poll this table every minute? I'm not sure what (if there is) the generally accepted best practice for this.
I wrote something similar for my senior project, basically a job scheduling framework.
I chose to go down the path of storing the "status" of the "job" in the database.
I wrote a manager windows service that implemented a WCF client (proxy)
I wrote a WCF Service that implemented my "worker host".
The manager service would read the queue from the database, and hand out work to all of my "worker hosts". The reason I had windows service perform this task as opposed to just having the UI talk directly to the worker host, was because it gave an extra level of control over the whole process.
I didn't like the idea of having "the network cable unplugged" from my worker host, and never getting a status update again from this specific job. So, the windows service gives me the ability to constantly monitor the progress of the WCF worker host, and if a connection error ever occurs (or something else unexpected), I can update the status to failed. Thus, no orphaned jobs.
Take a look at this
WCF Long Running Operations
There could be other options but they are nearly the same. You can also come up with some push notifications (I assume no data is returned) as one int the following link
WCF Push
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.