Flush cached data from IIS? - asp.net

I'm being asked to look into a problem that occurs intermittently on a WebServer running my team's application.
Essentially, we have a webservice that does a lookup between codes. If you have Code Type A, you can use it to look up the corresponding Code Type B. Periodically, when memory is running low, when this webservice is called, a null reference exception is being thrown. Essentially, this service loads a lookup file into cache with a dependency on the file, so if the file chages, the cache is reloaded with the new file. The priority on the cache object is set to default. I'm guessing that somewhere in the code, it isn't being verified that the cache object is still there and when memory on the server gets low, that object is dumped causing the error. I'd like to be able to recreate the error and verify before I start digging into this code.
Is there a way in IIS manager (or from the command prompt) to force a running web app to dump it's cache? I would think that this should recreate the condition and therefore recreate the bug. Not to mention, seeing the detail error should lead to the right section of code.
Thanks,
Steve Brouillard

My gut reaction would be to set the WebMethod's CacheDuration to zero, then back to whatever you want on an ongoing basis. I haven't tried this, but I think this would dump the cache then start it forming again...

I found a utility that can be added to ASP.NET apps that will allow you to dynamically manage the cache as a whole or individual cache objects. Thanks to .NET Rocks! and dnrtv.
Here's a link to the tool that I used. This allowed me to clear just the specific objects in question, on the fly, and prove the error.
Thanks to everyone for your help. ASP Alliance Cache Manager.
Steve

Related

Updating a Classic ASP website without interrupting service

A couple of questions:
1) How can I update a Classic ASP website/page without interrupting service (users getting an error or service unavailable message) or shutting the website down temporarily?
2) When updating/restoring a MSSQL DB via SQL Server Management Studio, will the website users get an error message?
Thanks in advance.
A smart practice is to use at least one separate development environment with the same setup as your production environment and debug all changes there to ensure that they work. Once your entire site is running and tested on the other, identical environment to your production environment, you should be able to simply move the files and they should work in production. This model being effective is dependent on actually being able to maintain environments as close to identical to each other as possible.
When updating/restoring a MSSQL DB
Be careful with your terminology; UPDATE and RESTORE are two very different commands.
If the database is locked by the changes being made, then it will be inaccessible to users and may cause error messages depending on your IIS and code setup. Scheduling a maintenance period and blocking user access to any pages that access the database is will help avoid messy errors and revealing any information about your infrastructure while the changes are being made.
It seems like you might want to do some basic research on development and databases both in order to make sure you understand what you're doing and can cover all of your bases. Looking up commands like RESTORE and UPDATE and using them correctly is crucial.
For example, when you rewrite one or more of your website files
via FTP, in that very moment when rewriting is taking place,
users will get a 500 Service Unavailable error. How can I avoid this?
This really shouldn't happen, although you could upload the files to a different folder, avoiding any delay there, and sync the files with a diff tool such as Winmerge (also helping you keep track of changes and revert quickly) when done uploading.

Keeping data in memory and persisting on Application_Disposed

I'm building a website (for personal use, low load) and instead of using an Access or MySQL database for data storage I'm thinking of having one XML file that I load and parse on Application_Start and then keep in memory (in static objects). The website then do reads and writes against these in-memory objects and I will finally persist all data to the XML file on Application_Disposed.
I'm aware that I'll need to make reading/writing thread-safe, but besides that, does anyone see any problem using this approach?
Yes, I see a big problem: There are a number of reasons to why the whole application might die without you knowing about it, and without your data being saved to that xml file.
You'll find Application_Dispose can get fired multiple times (so might don't be the best place to dispose your DI containers etc) whereas Application_End will only fires once (you can prove this by adding logging)
https://bytes.com/topic/asp-net/answers/561768-event-sequence
https://learn.microsoft.com/en-us/previous-versions/ms178473(v=vs.140)?redirectedfrom=MSDN
It seems VS2019 IIS Express doesn't seem to call Application_End as it should when you stop debugging, But IIS will.

ASP.NET Application Pool Recycling Issue

I have a Web Project setup that has both my WebForms and a WCF service. I am having an issue where every so often my application seems to recycle and i lose all singleton objects and session values. It does not appear to be a timeout issue, but maybe a memory leak of some kind. We can be using the app for a minute or so and then bam it just loses everything.
I have tried monitoring the directory for changes but found no changes to the filesystem at all. I also put a breakpoint in Application_Error and there are no errors being thrown.
I have been googling for two days trying to resolve this issue. The application is a direct duplication of a previous project that is working fine. The one thing I noticed that is different is my last project I used nHibernate for the backend and this project I switched to using Linq to SQL. I noticed that I wasn't handling the DataContext properly because I was diming an isntance of the DataContext inside my service calls and returning a value before ever disposing or setting the context back to nothing, so I figured it may not be closing. I tried instead of storing the datacontext in my "repository" class i stored it inside the operationcontext and explicitly dispose it on Application_EndRequest. That still hasn't resolved the issue.
Anyone have any suggestions or places I should look?
** UPDATE **: I believe i found my issue. I have objects that are using EntitySet and i am serializing those objects directly back using a serializable IList property with a linq query returning the list. When i tried to explicitly dispose of my datacontext before returning the data I am running into issues serializing those EntitySet's now because the datacontext is no longer active. I am going to try copying the data into a new blank object with regular Lists instead of EntitySet's and see if this will allow me to properly close my datacontext and resolve my issue.
Update is really a different question, but you really should not try and serialize stuff that comes off of an ORM -- lots of potential nightmares. Build yourself some DTOs.
In the IIS7 Console, select the specific application pool, and select "Recycling..." in the action pane to the left. It's a wizard that lets you define how the application pool recycles, and how it logs the recycle events to the event log (page 2 of the wizard).

What would be a good approach to use Thread or Thead Pool in ASP.NET

I am developing a component to create bespoke BulkImport functionality in ASP.NET. Underline this component will be using SqlBulkCopy class. There will be different file formats. The file is imported into a intermidiate table and is then transformed to the required tables. The upload file can be big and might take couple of minutes for processing. I would like to use Thread or Thead Pool to do asynchronous processing. Can you please suggest a good approach to handle this problem.
note: This is an internal application which would be used by max 2-5 person at any given time.
The main problem with firing up additional threads in ASP.NET is that the framework can rip the AppDomain out from under you (for example, if someone edits the web.config or IIS decides to recycle the worker process). If that happens, your worker thread is also terminated and you can't really control it.
If you don't think that'll be a problem, then it doesn't really matter, but I would suggest that a better solution would probably be to fire up the work in a separate process that you can then monitor from your web application.
That way, if someone edits the web config, or IIS recycles the worker process, the import process is running independently and you don't have to worry.
Here is my approach:
Ask the user to paste in the unc path to the file. Save this path into a table in sql.
Write a windows service to check for new entries in the path table. When finding a new entry, start processing the file. Update the tabel periodicly with the progress and check flags (below)
Have an ajax callback in the browser that checks the table for progress, returning as a percentage to the client. Allow the client to stop the process by adding some flags to the table.

How to update ASP.Net site dll without stopping site

Is it possible to update the site dll for a precompiled site without stopping IIS.
Currently, if I try to just copy the new file to overwrite the current file, All users receive runtime errors while the file is being copied. Is there a way to avoid this?
even if you don't stop, any change to the web.config file, BIN folder, App_Data or App_Code will force the .NET compiler to perform ...
and you will loose any Session variables in memory.
What I do is to use Session State in SQL Mode and if your system is set up like this, user will remain in the site (after a longer exposition to a page reload)
.NET will still invoke the compiler in order to compile the new set of instructions but soon it is done, all sessions will be read from SQL Server and because they are still there (and not lost with a memory refresh) users will remain in the website with current credentials.
it is a little bit slower than In-Memory Session State, but much more reliable, specially with Shared hosting :) this is the way to increse/decrese the minutes in your session, as Shared hosting do not allow it to change even if you do
Session.Timeout = 5;
their machine configuration will override everything you do, with SQL Session State, you will be able to set your time as this is all made by SQL Server.
Fell free to read this article to know how everything is done.
Hope it helps.

Resources