I have a project where users upload multiple 4-6MB AccessDb files to migrate into a AWS hosted SQL Server database. I think what is happening is that IIS maybe shutting down the process after some amount of time.
Its basically a file upload and then a c# static class that reads the mdb file and uses EF .core to copy into SQL Server. Using Visual Studio, i don't see any shutdowns and all test files migrate successfully.
Website built using .netcore 2.1 / c#
I have Web.config timeout set to requestTimeout="00:59:00" so that basically stops some 503 errors.
What I'm seeing is that if all browsers are closed(or maybe not) and maybe technically no connections to IIS, that after a few minutes, the migration stops. I'm not seeing new rows added to the database.
I want my c# .netcore processes to continue migrating whatever databases the user uploaded without IIS or whatever other process killing the connection.
Looking for tips I can update. I'm assuming there's other Web.config settings I can update?
It sounds like your code that processes the files is a background job in your application, so I think I know what's going on.
By default, IIS app pools are configured to shut down after 20 minutes of inactivity (no incoming requests). You need to disable that.
The option is called "Idle Time-out (minutes)" in the Advanced Settings of the application pool. Set it to 0 to disable it.
There are also options in there to automatically refresh the app pool, so review those and make sure they are acceptable to you (I forget what the defaults are).
It's not a good design decision to keep an http connection open for that long. First of all asp.net core will drop the thread after a while, and second the user could drop the connection by mistake. I would recommend doing this async to the user:
Receive the file, validate it.
Schedule a background job using either Hangfire or the builtin
IHostedService interface.
When the migration is complete email or notify the user some other
way.
Related
I have a WCF service application hosted in IIS. On startup, it reads the SQL connection information from the web.config and connects to the SQL Server to get the necessary information to bootstrap the application. If the SQL Server is unavailable for some reason, we want the service to shutdown - which I currently accomplish by throwing an exception.
The problem we have with this is that, if a service fails to start more than N times, IIS helpfully turns off the application pool - which means that, after the SQL Server connection issue is corrected (possibly entirely external to the IIS server), a sysadmin has to think to go an turn the app pool back on.
What I'd like to do is have the service gracefully exit. I know that there are ways to do this with ASP.Net Core (i.e., ways to hook into the lifecycle management of the process and tell it to exit), but have been unable to find anything like that for .Net Framework/ASP.Net.
Is there such an API that I can use?
Turns out that this method is available and works.
https://learn.microsoft.com/en-us/dotnet/api/system.web.hosting.hostingenvironment.initiateshutdown?view=netframework-4.8
Our Web Application uses an .net-core web api running on a loab balancer and an angular client. We access the DB using EF core.
We have a long running background-task that does a great amount of calculation and takes about 2-3 hours to do so, but will only be initiated by administrators of the application 3-4 times a year.
While the job is running we want to prevent users from adding/editing/deleting data and our client told us its even fine if the application is not avaliable for the duration as they will mostly do it overnight.
The easiest way to do this is to redirect users to an informationpage while the job is running but I have found no way of actually getting to the information if the task is running or not.
I could set a flag whether the job is running or not and just check that flag at every request but I found no way to access an applicationwide state.
I cannot save a flag to the DB because while the transaction is commiting at the end of the job (~1 hour) we cannot read from the DB
What baffles me most is that I have not found a single article or question about a problem like that which doesn't seem to be too outlandish to me, so I guess I'm missing something very obvious.
The simplest way is to store the value for your "Maintenance Mode" in a Singleton class on the server. (No database call needed). The value will remain there for as long as the server is actively running.
If distributed cache (as already mentioned) is not an option, you can run long running task in (uniquely) named transaction and then the check list of active transactions to determine if task is still running.
This is completely dependent on your setup but a simple way to approach this problem might be to make it the long-running job's responsibility to divert traffic from your site while it is running, and then undo that once it is finished.
As an example, if you were running this with an old-school .NET site in IIS the job could drop an app_offline.htm file into the site folder, run, then delete it again. Your setup is different, but if you could do something similar with your load-balancer (configure it to serve some static file instead of routing the requests to your servers) then it could work for you.
I have built ASP .NET Web API with SignalR to handle chat feature. The problem is, when client start SignalR connection, the application start some compilation (csc.exe or VBCSCompiler.exe), take 100% CPU usage and block other requests. What is more, the problem exist on all environments except my own and does not happen on all page refreshes - sometimes it connects without compile.
So far I have tried:
Remove my code which handle connections (OnConnected, OnDisconnected, OnReconnected)
Check differences in Web.config files between environments
Block csc.exe or VBCSCompiler.exe with permissions.
Try different SignalR transport method. LongPolling works the same way
Check SignalR connection log on client and server side (here you can see how long it takes to negotiate - 17s)
Check what process take so much time with a profiler. Here you can see StartApplication method which run some compile methods.
Do you have any idea what more should I check or do with that case?
I have found a solution.
The problem was that logs was saving in bin folder. Because of that, every entry in log file caused app pool recycle. You cannot keep your logs in bin folder!
In my case, there was some info entry during connection, and because of that my application was compiling something on almost every request.
I am currently having a strange issue with sessions, I've worked with MVC for quite a while and never had this in previous versions. Currently making a new system using MVC5 for the first time, all is well. Sessions are being set with no issues, however, if I modify a cshtml file in VS my session is killed.
Also I have a file upload feature which works, but when you upload a file and then navigate to another page the session is gone again. This is working locally and also on a Windows Server box we use for sandboxing.
Has something changed with the new versions of MVC regarding sessions? I've never had this before. I've got it set to use in-proc sessions, never normally needed to change anything but I have for the sake of things used cookieless, used cookies etc as options. Nothing seems to work.
If anyone has an idea that would be great.
It is interesting that you haven't observed this earlier - as always when you update the contents of your web site, IIS could recompile declarative resources causing the restart of the app pool which effectively removes all session data stored in memory.
A solution would be to switch to other, persistent session storages, sql is possibly the easiest to configure. You just need a sql server where you run the script that creates the session database:
http://support.microsoft.com/kb/317604
Another option would be to use the State Server:
http://msdn.microsoft.com/en-us/library/ms178586.aspx
The performance of the State Server is usually better than the SQl Server as the data is not persisted onto the disk. However, since the state server is a separate process, your application server won't loose sessions even when the app pool restarts.
I have one application which is developed in ASP .NET MVC 3 which using a SQL server database.
Apart from this, I have one console application which calls an external web service and update the same database with the information and business rules. (Basically we iterate the records from Web service and process the business rule and update the same database), we have configured the console application with Windows scheduler to process it periodically.
The problem is, when my Console application runs periodically, it uses the 100% CPU usage (because we're getting more than 2000 records from web service), and because of that my current MVC application is gets haging OR sometime works very very slow because both application are configured on same windows server.
Could anybody please do let me know that How would I resolve this problem where I want both the things on same server because I have central database used by both application.
Thanks in advance.
You haven't given any detail that anyone can really provide resolution, so I'll simply suggest how I would approach it.
First, I would review the database schema with a DBA to make sure there aren't things like table locks (or if there are, come up with strategies to compensate for them). I would then use the SQL Server profiler to see where (or if) there are any bottle necks in SQL server while these things are running. I would then profile the console application to make sure it's not doing something it doesn't need to be doing. I might even consider profiling the web site to see if there's anything in there that might be contributing to slowness.
After that, I would figure out how to get rid of the Console application and work its functionality into the site. Spawning another application on a given web request is not scalable. More than a couple of those come in at once and you've got the potential to bog the server down very easily.