I have one application which is continuously checking one wcf service response, and this service is hosted in IIS.
When I run this application and service is already running in background, at that time application is getting the response from the service for n-number of time.
But when I recycle the app pool, application is not getting any response from service. At this point of time I have to restart the application, and then it works.
Please suggest me a way or any changes I should do in service to get the response from it even after recycling the app pool. I don't want to restart the application.
Or if there is any workaround that I can do in application, so that it will come to know that new session is created or app pool is recycled.
I suspect you are storing the client proxy somewhere rather than periodically re-creating it. Once a WCF proxy has faulted, it cannot be re-used. Re-create it. If your WCF service is session-based rather than per-call you will run into such problems.
Related
I want to design an application that serves a REST API and also has a continuous process running that connects to websockets and processes the incoming data.
I have two approaches in mind:
Create a Windows Service with Kestrel running on one thread and the websocket listener on another. The API would be made accessible via a IIS reverse proxy.
Create the REST API with ASP.NET directly hosted in IIS and utilize the BackgroundService Class for the websocket listener as described here.
As I am new to the Windows Ecosystem I'd like to know if one of the approaches is more suitable or if I'm going about it the wrong way.
My understanding is that the Windows service approach should just work, but it seems more elaborate.
I'm unsure about the BackgroundService approach. The background process should really run 24/7. Are BackgroundServices designed for this? The docs always talk about long running tasks, but does it also work for infinite running ones with restart on failure etc.?
I'd recommend to host the continuous process in a Windows service as you have much more control over the lifecycle.
With a BackgroundService hosted on IIS, the process is controlled by IIS. In this case, it might be recycler from time to time or terminated of idle for some time. You can control this behavior with some configuration settings, but especially in combination with ASP.NET Core, the IIS process might be running, but the underlying Kestrel service is only started when a request hits the website.
If the two components do not rely on each other, you could also split them and have the best of both worlds, the web application hosted in IIS and the websocket listener running in a Windows service
I have a WCF service hosted on IIS, where during application initialization it start listening to the RabbitMQ and it subscribed to the Q say Q1, after long run of the service, we are seeing that the service is fetching the messages and it fails to processing it.
But we do have the different windows service which is also interested in the same events which is subscribed to the different Q say Q2, was able to process all the events even after a long run.
Why does the WCF is failing after long run, is there a thread pool sealing which will be imposed on Apppool ? Need help in debugging this.
Note: Both Queues (Q1 and Q2) are subscribing to the same message rout keys which is connected to the exchange.
Well I'm not sure about processing, but by default IIS-hosted anything AppPools recycle/expire after 20 minutes so it's entirely possible your WCF service is no longer running if its service methods have not been invoked.
Try setting your IIS AppPool timeout to 0 to disable timeout.
I have a WCF service that reads messages from MSMQ and writes messages to MSMQ. This is hosted in IIS. I have enabled net.msmq and http protocols on the WCF service in IIS. I have also given full permission on MSMQ for app pool I am running this service.
Once I have deployed this on the win server 2012 and I queue messages, WCF service does not pick up the messages. If my service name is myservice, Once I hit http://machinename/site/myservice.svc in the browser then on messages gets auto picked up.
Could you please know what is causing this behaviour.
Your problem is that your WCF service needs to listen to a queue, but it cannot do that until IIS decides to start the application.
This happens only when IIS needs to handle an HTTP request. Once it receives the request it will start your application, which can then start listening on the queue.
The easiest way you can fix this is not to use IIS to host a queue listener. Use a windows service instead.
If you're stuck with IIS, but you're using 7.5 or above, you can configure the application pool settings to make the application start when IIS starts:
<applicationPools>
<add name="appPool1"
startMode="AlwaysRunning" />
</applicationPools>
You also will need to ensure that Windows Activation Service is installed and running: https://msdn.microsoft.com/en-us/library/ms731053(v=vs.110).aspx
I have a 4 tier .NET application which consists of a
Silverlight 5 Client
MVC4 Web API Controller (Supplying data to the SL5 Client)
Windows Service - responsible for majority of data processing.
Oracle DB storage.
The workflow is simple: SL5 client sends a request to the rest service, the rest service simply stores it in the DB.
The windows service, while periodically polling the DB for new records, detects the new records and attempts to process them accordingly. Once finished it updates the records and their status in the DB.
In the meantime the SL5 Client also periodically polls the DB to see if the records have been processed. When they are, the result is retrieved and rendered on the screen.
So the question here is the following:
Is there a difference between spawning the same processing code (currently in the windows service) in a new discrete process (right out of the Web API Controller), vs keeping it as is in the windows service?
Aside from removing the constant DB polling that happens in the windows service, it simplifies processing greatly because it can be done on a per-request basis as the requests arrive from the client. But are there any other drawbacks? Perhaps server or other issues with IIS?
Yes there is a difference.
Windows services are the right tool for asynchronous processing. Operations can take a long time without producing strange effects. After all, it is a continuously running service.
IIS on the other hand, processes requests by using a thread pool. Long running tasks have the potential to exhaust that thread pool, so this may cause problems depending on the number of background tasks you start. Also, IIS makes no guarantees to keep long running tasks alive. If the web site is recycled, which happens regularly in a IIS default installation, your background task may die.
I have several services running. I can call everyone from a client application. I am trying to call into one service from another service (same application - they are hosted in an application for testing but can also run as a windows service).
The call I use to do this from the client is simply create the factory and CreateChannel and then open.
When I do this in a service trying to connect to another service I don't get an error it just hangs and eventually times out. I have no idea what is wrong.
I am using net.pipe://localhost/test as my endpoint and transport.
This was really stupid but (and) I will post the issue to help others that may run into this...
All of my service was running single threaded so when I called into another service it was blocking itself. I now start my threads on backgroundworker threads and the issue is gone.
Thanks