i created a loop up to 100 to insert any data in db.
but when i close my browser I hope it stops but it in background it continues looping and filling my db. how can I stop it?
thanks
No guarantees that it would work, but you could try the HttpResponse.IsClientConnected property.
for (int i = 0; i < 100; i++)
{
if (!Response.IsClientConnected) break;
// insert the next row
}
It sounds like you have started off this process from an ASP.NET form with the server-side code doing the looping in response to something (either the ASP.NET form loading, or clicking a button etc).
Note that closing your browser window will NOT stop any long-running code process that you have invoked on the "server". Although this may be running on the same machine, the "server" here is the IIS/Cassini process that serves up your webpage to the "client" (your browser).
In order to stop this, you'll need to stop/shutdown the IIS or Cassini (Cassini small web server used by Visual Studio when running a web app on your local development machine), or stop/shutdown the SQL Server process.
EDIT: I noticed the downvotes for the other answer than mentions stopping IIS/SQL. This, of course, is a "last-gasp" mechanism for stopping a long-running process invoked by the "client" but running on the "server". If this were to be done in a "real" application, and you wished to allow the user to cancel a long-running application, an approach as suggested by Marc would be required (i.e. use AJAX, "poll" the web-page with AJAX "refreshes" and respond to subsequent user input (i.e. button click)).
If you are doing this at the server in a single http request (for example, responding to a button event in your code-behind), then the server doesn't really care much about the browser. If you want the inserts to stop when the browser stops, I would suggest perhaps doing this via an ajax loop - but note that this will be considerably slower, as you will have 100 round-trips, and 100 separate sets of processing at the server.
How about a band-aid solution:
Let your webpage send keep-alive AJAX calls every 5 seconds or so to the server and abort if the keep alive is not received :)
Shut down SQL Server and/or IIS.
Edit: ...assuming that you made a programming mistake, you DB keeps filling up and you desperately want to stop it -- this is how I understood your question.
Related
I am writing an application for the web, but, the problem is a task may take a long time to complete (minutes or hours). During this time I assume the website will time out or similar.
Let's assume the user can click the Start button and various processes are carried out. My question is about keeping the process (the task) alive, even if they leave the website, without configuring IIS (if possible).
Simply, if I spin off a new thread to perform a long winded background task, is that background task still owned by the application (the website) and if I close the application (the website) will it automatically be aborted or will it continue?
I guess the better way would be for the code behind to start up a process on the server (a different application) but, I'm more keen on understanding how the thread works.
To do that, start that Thread using Ajax. It would be sent asynchronously to the server and server can work on it until it completes the task.
Once you send the request to server browser doesn't need to be active. Server has to do the work and Browser is needed only to show the result of the request. Once the user would send the request, its not required for him to stay there. He can leave, and the server would continue the work.
User can navigate away from the Website and don't have to stay in the website for the process to complete. It would then depend on the System to complete the task.
I wonder if the following is possible:
I have a dll that I have referenced in my web site. This dll makes a remote socket connection. The socket connection is waiting in the background and the dll reports back data through events after the socket has received some data.
The connection is opened during load of page.
Now, I would, for example, like to update a label on the page when new data has arrived.
I am not sure how this would work. I assume that I could set some kind of timer on page that updates a control but it does not seem "optimal" as I already call code behind through my events. "Optimally" the UpdatePanel or whatever updates the interface would wait for events and "update" when events has occurred and not based on time.
My question is - is this possible?
You can use techniques called "long pulling" or "web sockets".
There are libraries, like SignalR that can help you.
They generally use web sockets when client's browser supports and long pulling when not.
Using these libraries you can "push" commands/data from server to client's browser, just as you want.
Server cannot push the client, this is the rule how web works.
There are two possible ways to complete your task.
Put timer on the page and make requests on server too see, if something changed
Open long pulling connection between client and server, like facebook does. That listens
to the events and gets data from the server. It can be, for example xmpp or any other.
You should think about turning this around; rather than initiate the call from the code behind asynchronously and then update the client, you should deliver your original page to the client.
Once the page has been loaded client side, you can make an AJAX call to the server to retrieve the data you want - and display a little "I'm loading" symbol while this happens.
Page Methods are ideal for this.
The classic ASP.Net web page is supposed to last for the duration of the users request. When a postback happens, it effectively rebuilds the state of the call from the user's viewstate, session and any other state you've maintained. It never cares if the user goes away, for example (although it might feel a bit lonely).
Having it hang around for longer is problematic in a number of ways, however, you can implement client callbacks. However, although the server initiates this, the client manages the lifecycle, so it's analogous to page methods.
In an asp.net web form, I keep getting a connection reset error message. The page is doing a some long running processing (about 2-5 minutes).
I have no problem when the web request comes from the same machine as the web server. But when the request originates across the network, I get a connection reset error about 1:30 or 2 minutes into waiting for a response.
I have set the in web.config for this application and put the application it's own application pool.
What else can I try?
Edit
The purpose of this page is to accept input from the user, calculate something, and send the result back to them. The long running calculation isn't something I can offload until a later time.
A common way to handle this is to kick of a background thread to process your data, but immediately return an identifier to the browser, normally as a link. When the link is clicked, the server checks to see if processing is complete - if it is, show the results, if not, display a "please wait" message and the link again, or auto-refresh the page...
Do not make the browser wait for this long. Make the request asynchronous, make it return right away. If you need to make user wait - do it using Javascript
I'm having an issue sending large volumes of emails out from an ASP.Net application. I won't post the code, but instead explain what's going on. The code should send emails to 4000 recipients but seems to stall at 385/387.
The code creates the content for the email in a string.
It then selects a list of email address to send to.
Looping through the data via a datareader it picks out the email address and sends an email.
The email sending is done by a separate method which can handle failures and returns it's outcome.
As each record is sent I produce an XML node in an XML document to log each specific attempt to send.
The loop seems to end prematurely and the XML document is saved to disk.
Now I know the code works. I have run it locally using the same SMTP machine and it worked fine with 500 records. Granted there was less content, but I can't see how that would make any difference.
I don't think the page itself times out, but even if it did, I was sure .Net would continue processing the page, even if the user saw a page time out error.
Any suggestions appreciate because I'm pretty stumped.
You're sending lots of emails. During the span of a single request? IIS will kill a request if it takes longer than a certain (configurable) amount of time.
You need to use a separate process to do stuff like this. Whether that's a Timer you start from within global.asax, or a Thread which checks for a list of emails in a database/app_data directory, or a service you send a request to via WCF, or some combination of these.
The way I've handled this in the past is to queue the emails into a SQL Server table and then launch another thread to actually process/send the emails. Another aspx utility page can give me the status of the queue or restart the processing.
I also highly recommend that use an existing, legit, third-party mailing service for your SMTP server if you are sending mail out to the general public. Otherwise you run the risk of your ISP shutting off your mail access or (worse) your own server being blacklisted.
If the web server has a timeout setting, it will kill the page if it runs too long.
I recommend you check the value of HttpServerUtility.ScriptTimeout - if this is set then when a script has run for that length of time, it will be shut down.
Something you could do to help is go completely old-school - combine some Response.Writes with a few Response.Flush to send some data back to the client browser, and this tends to keep the script alive (certainly worked on an old ASP.NET 1.1 site we had).
Also, you need to take into account when this script is being run - the server may well also have been configured to perform an application reset (by default this is set to every 29 hours in IIS), if your server is set to something like 24 hours and this coincides with the time your script it run, you could be seeing that too - although the fact that the script's logging its response probably rules that out - unless your XML document is badly formed?
All that being said, I'd go with Will's answer of using a seperate process (not just a thread hosted by the site), or as Bryan said, go with a proper mailing service, which will help you with things like bounce backs, click tracking, reporting, open counts, etc, etc.
I know this question has been asked many times, but my problem is a little different.
I have page which lets user download and upload excel file. During downloading excel, it takes approx 2 mins to generate the file. I have added checkpoints which updates the database with status like (started processing, working on header ...etc). I have done the same thing for upload.
I also have a ajax request which checks the database in fixed interval and prints status to user to give feedbacks like (started processing, working on header ...etc).
The problem is, i get the feedback only when the process is complete. It looks like the session is blocked during the background process and any other request(ajax) are only completed once the background process is over. ajax makes approx 10 requests within 4 sec intervals.I get the 10 response back only in the end.
I have tried two iframes and also frames, one running the ajax and other running the process, Doesn't work. i tried separate browser(Process running in IE, ajax running in FF) and that works (so i now my code works). Can anybody advise? Thanks
p.s. My environment is IIS 6, ASP.NET 3.5 with MVC 1.0 browser is IE6.0
Your browser has a limitation on the number of connections that can be working concurrently.
I believe IE has a limitation of 2 connections. That means that even if you are running AJAX requests you can only have two requests running concurrently at the same time.
That is most likely why you're not seeing results until the end, because it's processing other connections and doesn't get to the status request until it's already done. That also explains why it works when you do it from different browsers, because you don't suffer from the same connection limitation.
Here's an article that details the issue.
This is exactly what i was looking for
(asynchronous-processing-in-asp-net-mvc-with-ajax-progress-bar)
Using delegate BeginInvoke of IAsyncResult helped with the blocked session