I have an app running in its own app pool that writes often to a text log file. When the 29-hour fixed recycle hits, I usually run into problems because the new process is launched while the old process is still there. This causes "can't open the file because it's in use by another process."
First I simply tried to set Disable Overlapped Cycle to True, but that takes my service off the air for 90 seconds or more, which is not good. If I reduce the Shutdown Time Limit I suppose it would help, but I'd prefer not to kill the process immediately.
I tried setting up an Application_End handler in Global.asax, but I find it's almost never getting called because (I think) my process is still running a thread somewhere (possibly the logging process).
I tried Application_Disposed but so far it does not get called when IIS kills the process after the shutdown time expires, and it's probably too late by then if I go back to overlapped recycle, which I think is preferable.
What I need is a signal from IIS that says "Hey, I want you to stop," that lets me close the log file immediately, but that does not seem to exist.
Any suggestions would be appreciated.
The Problem is in your App Itself and not in IIS.
Just Disposed the object after you calling or writing into text file to avoid this issue.
I've been encountered that same way before. I also writing to a text file for a log then error occurs "can't open the file because it's in use by another process." but when i disposed the object not just the word disposed, you have to check it carefully for a proper disposal.
Its all gone and run the app normally.
Hope it helps
Related
Different users trying to access different application routes with heavy manipulation of data. At the mid time one of the request failed due to internal server error and my whole application has been crashed. Thats why other request has been failed because build has been crashed. Is there any solution to handle this situation?
If your program has thrown an uncaught error and crashed then there's nothing you can really do other than start it back up again. You could use something like pm2 to automatically restart your node process when it crashes, and then at least future requests that come in should work (although you will lose any in memory data from before the last crash).
Another thing that I think would help you would be to move your backend onto a serverless architecture where each invocation of your code is independent of the others.
And of course try to fix the code so that it handles things gracefully and doesn't actually throw errors. :)
I'm currently creating a continous webjob that will do polling to an API, and then forward messages to an Azure Service Bus. I've managed to get this to work just fine, but I have one problem; what if my app crashes for whatever reason? What if there's an uncaught exception, or something goes wrong, and the app stops running. How do i get it to run again?
I created a test app, which will send a message every to the Service Bus, then on the 11th message it will crash due to an intentionally placed NullReferenceException. I did this in order to investigate behaviour whenever/if the app crashes.
What happens is that the app runs just fine for the first 10 seconds (as expected). Messages are being sent, and everything looks good. Then after the 10th second, when the exception occurs, nothing happens. No log in Azure saying there was an exception, no reboot - nothing. It just stands there as "running", but messages are no longer being sent.
How do I deal with this? It's essential that the application is able to reboot if it fails. Are there any standard ways to do this? Best practices?
Any help would be appreciated :)
It is always good to handle most of the failure scenarios in the system by ourselves rather than to let the hosting environment to react for the failures.
My suggestion would be to have a check in the code for exceptions like any try catch block in your executable script to catch different kind of failure scenarios and instead of throwing the exceptions, log it your self or take any retry operation if required.
Example, when you got a junk data to process and it failed. Then you can try to do the operation again for eg. 3 times and then finally push a log to deadletter account to manually take care of such junk inputs. And don't let the flow be stopped by throwing the exception but instead handle it your self by logging a message which needs manual intervention.
In any GUI or Web applications, if there is an exception then the flow is re initiated by user click and system will respond. But here as it a background processor, it is ideal to avoid all such control flow blockers.
Hope this would help.
I have an Application that facilitates file uploading to the server using http request.
I'm using HttpSendRequestEx and HttpEndRequest to do the file uploading.
And it is working fine. And the uploading is performed inside a separate thread.
in which the files to be uploaded are processed one by one.
Now a new requirement is that the user should be able to cancel the uploading at any time.
As the uploading is performed inside a thread currently I dont have any control over that.
So as a work around, what I have done is,
When the user clicks the button for cancelling the upload,
the following HINTERNET handles
hSession returned from InternetOpen
hConnect returned from InternetConnect
hRequest returned from HttpOpenRequest
has been closed using InternetClosehandle function.
As these handles are used inside the thread, it is not able to access directly.
So I have declared these as static members of the class in whcich the thread runs.
So that I can access it directly when the button click is occurred.
By doing this the request which is under process gets cancelled immediately.
But I dont know whether this is a good way. So I would like to know whether there may have any security issues on proceeding this logic..
Also is there any option better than this....
Kindly have a comment on this. Expects an expert advise on this..
Thanks in advance
From a TCP socket point of view, this is a correct way to interrupt the request: It is perfectly legal to close a socket to stop and close a connection doing some work on a different thread.
That said, WinInet is more than a wrapper around a socket so we can't be sure that there's no resource or memory leak.
I would test it by writing a test program that creates a lot of such interrupted uploads and look for resource leaks on the Performance tab of the process in Process Explorer. I would especially watch the Handles count and probably the Virtual Memory as well.
Also, before closing the handles, you could try to close the HTTP connection by calling HttpEndRequest(), which may possibly clean a little more things.
I have an NServiceBus configuration that is working great on developers machines and in my Development Environment.
However, when I move it to my Test Environment my messages just start getting tossed.
Here is the system:
An app gets a TCP message from a Mainframe system and sends it to a MSMQ (call it FromMainframe).
An application hosted in IIS has a "Handle" method for that MSMQ and processes the messages from the mainframe.
In my Test Environment, step two only half way happens. The message is popped off the MSMQ, but not processed by my application.
Effectively my data is LOST! NServiceBus removes them from the Queue but I never get to process them. They are not even in the error queue!
These are the things I have tried in an attempt to figure out what is happening:
Check the Config files
Attach a remote debugger to the process to see what the Handle method is doing
The Handle method is never called (but when I attach to the Development Environment my breakpoint in my Handle method is hit and it all works flawlessly).
Redeploy my Dev version to the Test Envioronment and try step 2 again (just in case the versions were not exactly the same.)
Check the Config files again
Check that the Error queue is not filling up
The error queue stays empty (I wish it would fill up, then my data would not be LOST).
Check for any other process that may be pulling stuff from my MSMQs
I Turned off my IIS website and the messages in the FromMainframe queue start to backup.
When I turn it back on, the messages disappear fairly fast (but still not all at once). The speed that they disappear is too fast for them to be processed by my Handle method.
Check Config files yet again.
Run the NServiceBusTools\MsmqUtils\Runner.exe \i
I ran it, rebooted, ran it again and again for good measure!
Check the Configs again (I must have missed SOMETHING right?)
Check the Development Environment Configs are not pointing to the Test Environment
I don't think it is possible to use another computer's MSMQ as your input queue, but it does not hurt to check.
Look for any catch blocks that could be silently killing my message.
One last check of the Config files.
Recreate my Test Environment on another machine (it worked flawlessly)
Run my stuff outside of IIS.
When I host outside of IIS (using NServiceBus.Host.exe) it all works fine. So it has to be an IIS thing right?
Go crazy and hope that stack overflow can offer any kind of insight.
So I know enough about what happened to throw out an "Answer".
When I setup my NServiceBus self hosting I had a call that loaded the message handlers.
NServiceBus.Configure.With().LoadMessageHandlers()
(There are more configurations, but I omitted them for brevity)
When you call this, NServiceBus scans the assmeblies for a class that implements IHandleMessages<T>.
So, somehow, on my Test Environment Machine, the ServiceBus scan of the directory for a class that calls IHandleMessages was failing to find my class (even though the assembly was absolutely there).
Turns out that if NServiceBus does not find something that handles a message it will THROW IT AWAY!!!
This is a total design bug in my opinion. The whole idea of NServiceBus is to not lose your data, but in this case it does just that!
Now, once you know about this pitfall, there are several ways around it.
Expressly state what your handler(s) should be:
NServiceBus.Configure.With().LoadMessageHandlers<First<MyMessageType>>()
Even further protection is to add another handler that will handle "Everything else". IMessage is the base for all message payloads, so if you put a handler on it, it will pickup everything.
If you set IMessage to handle after your messages get handled, then it will handle everything that NServiceBus can't find a handler for. If you throw and exception in that Handle method that will cause NServiceBus to to move the message to the error queue. (What I think should be the default behavior.)
Sometimes when IIS restarts the app pool it will start a new instance of my application before the previous instance is shut down completely. This causes me alot of problem so i wonder what i can do about it.
The course of action goes something like this. (spanning about 20 seconds)
Application is running, let's call this instance A.
Restart initializes
A new instance is started, let's call this B (Logged by Application_Start)
Incomming request is processed by instance B, this invalidates all data A has cached.
Timer on instance A is triggered, assumes its cache is valid and writes something invalid into the persistant storage.
Instance A is shut down (logged by Application_End)
Preferable i would like to disable the above behavior completely, IIS should only allow one instance. If not possible, can i in my code detect if other instances is alread running and then wait for it to quit inside application_start? If not possible, what is the best way to work around this?
Disable overlapped recycling:
"In an overlapped recycling scenario,
the process targeted for a recycle
continues to process all remaining
requests while a replacement worker
process is created simultaneously. The
new process is started before the old
worker process stops, and requests are
then directed to the new process. This
design prevents delays in service,
since the old process continues to
accept requests until the new process
has initialized successfully, and is
instructed to shut down only after the
new process is ready to handle
requests."
http://msdn.microsoft.com/en-us/library/ms525803(v=vs.90).aspx