"when the application pool is "alive" the service picks up the messages correctly, but as soon as the application pool gets recycled (because of timeout or any other reason), the service stops picking up the messages, that just sit
in the queue until the service starts again by browsing to the service webpage"
Have you find a solution, to activate the service without manualy browse the service.
The solution is to configure auto-start. Then IIS will start your service immediately without waiting for the first request.
But first you need to add AppFabric to your ISS, then you need be sure you have the "Start Mode" option in your pool advance settings.
Note: In my windows 7 IIS7 didnt work, but in my windows server 2012 R2 IIS8 Works perfectly
Also you can check this similar question:
MSMQ WCF hosted in IIS
Related
I have a .Net application hosted in IIS 10 running on Windows Service 2019. Sometimes the website stops responding (usually when running E2E tests). Even after restarting Website/Application Pool/IIS/Machine it doesn't work.
Looking in Event Viewer I see errors like these:
Forms authentication failed for the request. Reason: The ticket supplied has expired
Failed to stop a listening channel for protocol 'http' at allotted time from worker process serving application pool
A process serving application pool exceeded time limits during shut down
In HTTPERR files I see a lot of messages containing Connection_Abandoned_By_ReqQueue and Connection_Dropped
In inetpub log files I can't see any relevant, just the url requests.
To add more information, we have signalr installed and sometimes errors appear in the events, errors with messages like:
The user identity cannot change during an active SignalR connection.
Any idea what might be causing this?
So when I run my two services locally, I can hit service A which sends a command to service B which picks it up and processes it. Pretty straight forward. However, when I publish these to my web server and I send a request to service A which sends it to service B (I can see the message in service B's queue) but it won't get picked up and processed. I created an endpoint on service B that simply returns an OK response -- if I call this endpoint, effectively "touching" the service, everything kicks on and the messages get processed from that point on.
I figured maybe this had something to do with with late compiling, so I changed the publish to precompile on publish, but I get the same result.
Is there a way to have the service start processing as soon as it is published? Also worth noting that both services are WebAPI 2
Another option (probably more “standard”) would be to move the “handlers” into a Windows Service instead of a web application.
For this Windows Service you can leverage the NServiceBus Host which will turn a standard class library into a Windows Service for you. They have a good amount of documentation about this here: https://docs.particular.net/nservicebus/hosting/nservicebus-host/?version=Host_6
I would argue that this is more stable as you can separate the processing of sending commands (Web Application / WebApi) and processing commands / publishing events (NSB Host). The host can sit on the web server itself or you can put these on a different server.
Our default architecture is to have a separate server run our NSB Hosts as you scale web applications and NSB Hosts differently. If you run the NSB Host on the web server, you can get issues where a web app gets too much traffic and takes the NSB Host processing down. You can always start simple with using 1 server for both, monitor the server and then move things around as traffic increases.
Not sure if this is the "right way" to do things, but what I ended up doing is setting up each site to be always running and auto initialize.
App pool set to "Always Running"
Website set preload enabled = true
Web.config has webServer entry for application initialization doAppInitAfterRestart="true"
Web Role added to server "Application Initialization"
With those things being set, the deployment process is basically to publish the site and iisreset. If there are better options, I'm still looking :)
I have a dedicated server in Aruba, which is Windows Server 2012 R2 and as you can see from here:
I created a simple test web site to see if everything works and the relative application pool starts. Anyway, if I perform
http://94.177.162.33 (the IP address assigned to my server from ARUBA) or
http://localhost
I get "Service Unavailable. HTTP Error 503. The service is unavailable." and I see that the relative application pool test has stopped.
Well, I have never worked with Windows server before and I barely know what is IIS but I wouldn't know hot to solve this issue.
what am I missing?
This is wha I have in Event Viewer:
Follow below steps:
Open Internet Information Services (IIS) Manager > Application pools > choose application pool > Advanced Settings.
Scroll down to Rapid Fail Protection and change the option Enabled from True to False. Click OK to apply the changes.
Start the Applicaiton Pool
I have an asp.net application running on IIS 7.5 , Windows Server 2008 R2 – using an application pool in classic mode, framework version 4.
Sometimes I am running into the following problem:
The application can work for a few days, but all of a sudden I receive an http error 503 – server unavailable.
When I look at the application pool it seems to be running (I see it started), but it actually FREEZES – every request to it is responded with 503.
At the worker processes list (in the IIS manager) I see a lot of requests unhandled.
It's important to mention that other asp.net application running under other application pools are working just fine which means the IIS is working fine and the problem is only in this specific application pool.
When I researched the http error logs I saw the following error logs in the Windows\System32\LogFiles\HTTPERR folder:
In regular settings when everything works fine I noticed records of
"Timer_ConnectionIdle" (a normal thing from what I have read).
At a certain times I notice an appearance of "Client_Reset" records.
15 minutes after the "Client_Reset" errors started->records of "QueueFull appear".
In order to work with the application I am doing an iisreset (I guess a recycle for the pool will be enough also).
I will be happy to receive any help or suggestions.
EDIT:
It's important to mention that nothing related gets written to the IIS logs, or the System and Application logs. This error occurs before.
Without more information about your problem, most quick fix will be to Configure Recycling Settings for an Application Pool. Since your problem is about request queues, you can choose option After reaching a number of requests.
When I encounter HTTP 500 errors, I find that enabling IIS Tracing is very helpful. Below is a link that describes the process of enabling tracing and then reviewing the trace. The first section of the site describes how to install IIS, so you probably want to skip to the section labeled "Enable Failed-Request Tracing."
Troubleshooting Failed Requests Using Tracing in IIS 7
Edit:
Since you're getting a QueueFull error, you may want to monitor the request queues. The easiest way to do this is using Perfmon. On the server with IIS, open Performance Monitor and add the appropriate counters under "HTTP Service Request Queue." In your case, "Current Request Queue" for the ailing Application Pool would likely be of value.
We've implemented a "background service" in our Asp.Net web app that receives messages from MSMQ at random intervals without requiring an HTTP request to start up the application. We auto start this web app using a serviceAutoStartProvider.
Everyhing works when IIS initially starts up, the server is rebooted and so on, we receive messages just fine. BUT if we just stop the site in IIS (not touching the application or app pool), the application stops receiving MSMQ messages. And when we start the web site again, the serviceAutoStartProvider is not called again, so our app does not start listening to MSMQ messages again!
If we issue a HTTP request against the web app after the IIS site has been stopped and started again, it starts listening to MSMQ messages again.
Shouldn't our "background service" web app continue to listen to MSMQ messages even if the IIS site is stopped? It won't get any requests, but I think it should continue to run.
What exactly happens in an Asp.Net application/app pool when the IIS site is stopped? Any events fired that we can hook up to? The app pool claims to be "started" in IIS manager, but code is not running in it.
Why isn't our serviceAutoStartProvider called when the site is started again? I believe it is "by design", since the application isn't really stopped. But the applications isn't running, either, has to be waken up by an actual HTTP request.
When the IIS Web App shuts down (eg. due to no new HTTP(S) requests for the timeout time) the .NET app domain (within the app pool worker process) completely closes and unloads. This includes all background threads, including those used by the .NET thread pool.
A Web App can be configured with a longer (or no) timeout, then background worker threads could continue to process work.
But better would be to either run such workers in a specialist service process managed completely separately.
Or, even better, use IIS application hosting with WCF to create the MSMQ listener. I understand in this case the integration of Windows Process Activation Services with IIS would restart the Web App if a new message arrived after it had been shutdown.
I would host the MSMQ listenner in a windows service. Why couple it to IIS?
UPDATE
Actually what I mean is why couple the MSMQ and ASPNET in the same app pool?
You can now use "Application Initialization" feature of IIS8 (and IIS7.5), more information including version availability and usage documentation can be found at:
http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-application-initialization
This replaces "Application Warm-Up Module" which is no longer supported, and provides us with proper control over component/service initialization in an "always running" scenario.