In sharepoint my web part is calling a web service. This web service does some heavey processing in the background. On large data sets the page asks for your username and password after a certin period of time before a response is returned. It seems to be timing out. What setting timing out and where do I change this limit?
http://support.microsoft.com/kb/912451 upping this value from 30 seconds has stop the autheication problem for me. Running into a new issue backend now for it timing out but the browser seems to be fine.
Related
We're getting a very weird alternating delay in IIS after migrating to 64bit.
We have a web service (built using AnyCPU and .NET 2.0) referencing a COM EXE built using FoxPro to access MYOB.
The web service is configured to impersonate a specific user account.
Initially we thought the delays we were experiencing were due to reloading the MYOB data (400MB+) over the network repeatedly, so we added in some logging to be sure, and found the following.
It seems to delay every second request, with the first request being fast.
In the security event log we get event ID 4672 (special privileges) for the account about 1 second after the call is made from the client.
X time later we log a call on the first line of the method called (before everything else, including the try/catch)
X may be 2-6 seconds when things are working, and up to 7 minutes when it's not (usually about 80 seconds).
Any suggestions for where I can look for more information or possible causes?
I have an MVC3 application that takes 30+ seconds for global.asax Application_Start() to execute. When a user hits the site for the first time after the App Pool was reset, the browser just sits there with a "waiting for website..." message.
Is there a way to show a "Loading data..." message/page to let the user know that everything is OK and to be patient?
No, there's no way to show any messages from Application_Start. IIS 7.5 has a cool AutoStart feature which allows you to preload your application in memory and thus avoid the long waiting. Another possibility is to have some external service that queries your site at regular intervals so that it doesn't get unloaded by IIS.
If you cannot use this feature, then you will have to reduce/optimize the amount of work you do in your Application_Start so that it doesn't take 30 seconds.
Not within the same .net application - you can't show anything from within Application_Start. You could create another small app as a landing page which polls for a response from your main app and then redirects once it gets one.
But a better solution would be to move some work out of Application_Start - can't you let the user arrive at your first page and then call an initialization method once they have landed?
You can't do that in that particularly way, as there is no response from the server, and for such, you can't do anything.
But how about to implement a heartbeat that will query any URL of your application avoiding it not to enter in stand mode?
an idea: Set an external service to query your application every 5 minutes:
RestSharp requests on momentapp's restful api
I am currently debugging some issue about this.
We have a ASP.NET web application and I am debugging on Cassini. When I tried to use IE and send out the request to the server, some time (e.g. in about 20minutes) is needed to process and then send out the response.
In case of multi-tab IE, I tried to send out the requests in different tab at about the same time to the same server but the response is handled only after the one of the response is sent out.
If a new instance of IE is started and the requests are sent out in these different instances, the server can process and send out the response almost simultaneously. After doing some research I found that IIS express may solve my problem, but I cannot. Anyone has experienced similar problem or have I missed out some really important things to check with first?
Thank you for your help.
This is primarily due to ASP.net's session state variable and the fact that only one request at a time may have R/W access to a particular session (as determined by the SessionID cookie).
Any additional requests requiring any form of session access (since Read/Write is the default) will be blocked until the previous request has been completed.
Based on the following links:
http://johnculviner.com/asp-net-concurrent-ajax-requests-and-session-state-blocking/
https://msdn.microsoft.com/en-us/library/ms178581.aspx?f=255&MSPPError=-2147217396
I think that you miss the point that the session is lock all request leaving only one per time to run.
Read about that and why:
Replacing ASP.Net's session entirely
Also : Web app blocked while processing another web app on sharing same session
The reason is that Sessions in ASP.NET are not thread safe. Therefore ASP.NET serializes access to requests from the same session.
If you have a multi-tab IE then your tabs share one session. The first request is executed right off and the other ones are queued. If you have different instances then each of them creates a new session and therefore the request are executed in parallel.
I've created a very small monitor web-app, which periodically polls other websites to check if they're alive. If they're not I'm sent an e-mail so I can react (e.g. if the site responds 503)
However my problem is that the monitor web-app is shutdown when the AppPool recycles, and it's never started again because it gets no requests.
Is there a way to ensure it'll start again after a recycle, restart of the server or similar ?
Currently it starts a background thread in global.asax Application_Start, and the thread is then in charge of keeping the monitor web-app alive, by polling it as well as the other sites.
This way it'll get a HTTP request every so often. However this obviously only works for keeping it alive, when it has actually been started.
I've read a bit about IIS Warm Up modules, however the site is hosted on a server I've no influence on, so that's not possible.
The site is built using ASP.Net 4.0 and it runs on an IIS 7.5 server.
Hope you have an idea :-)
I use uptime robot to ensure my application is always spun up. The beauty of this system is it only asks for the headers of a page on your website and gets status codes like "200-ok", "404-not found", etc. every 5 minutes. This means that uptime robot does not add noise to Google Analytics as the page is never requested.
Seems to work like a dream for me and its FREE for upto 50 sites!
You should implement this as a windows service or console app run via a scheduled task. A web site is really not the appropriate type of application.
I Agree with tvanfosson but if you need it right now, you can still configure the application pool not to recycle.
http://technet.microsoft.com/en-us/library/cc753179(WS.10).aspx
It's better to make this up as a windows service or a scheduled console application. If you want to keep it as a webapplication then you can have 3rd party send pings to your application to keep it running. At my current client this is done with http://www.pingdom.com/ but there are other alternatives to it.
I'm encountering a situation where it takes a long time for ASP.NET to generate reply with the web page (more than 2 hours). It due to the codebehind running for a while (very long, slow loop).
Browser (both IE & Firefox) stops waiting for the reply (after about an hour) and gives generic cannot display webpage error (similar to what you would see if you'd try to navige to non-existing server).
At the same time asp.net app keeps going (I can see it in debugger) and eventually completes.
Why does this happen? Are there any settings in web.config to influence this? I'm hoping there's a timeout setting that I'm missing that's causing this.
Maybe a settings in IE or Firefox? But I think they wait while the server is keeping connection alive.
I'm experiencing this even when I launch app in debug mode (with compilation debug="true") on my local machine from VS (so it's not running on IIS, but on ASP.NET Dev Server).
I know it's bad that it takes so long to generate the page, but it doesn't matter at this stage. Speeding it up would take a lot of extra work and the delay doesn't really matter. This is used internally.
I realize I can redesign around this issue running logic to a background process and getting notified when it's done through AJAX, or pull it to a desktop app or service or whatever. Something along those lines will be done eventually, but that's not what I'm asking about right now.
Sounds like you're using IE and it is timing out while waiting for a response from the server.
You can find a technet article to adjust this limit:
http://support.microsoft.com/kb/181050
CAUSE
By design, Internet Explorer imposes a
time-out limit for the server to
return data. The time-out limit is
five minutes for versions 4.0 and 4.01
and is 60 minutes for versions 5.x, 6,
and 7. As a result, Internet Explorer
does not wait endlessly for the server
to come back with data when the server
has a problem. Back to the top
RESOLUTION
In general, if a page does not return within a few
minutes, many users perceive that a
problem has occurred and stop the
process. Therefore, design your server
processes to return data within 5
minutes so that users do not have to
wait for an extensive period of time.
The entire paradigm of the Web is of request/response. Not request, wait two hours, response!
If the work takes so long to do, then have the page request trigger the work, and then not wait for it. Put the long-running code into a Windows service, and have the service listen to an MSMQ queue (or use WCF with an MSMQ endpoint). Have the page send requests for work to this queue. The service will read a request, maybe start up a new thread to process it, then write a response to another queue, file, or whatever.
The same page, or a different, "progress" page can poll the response queue or file for responses, and update the user, assuming the user still cares after two hours.
For something that takes this long, I would figure out a way to kick it off via AJAX and then periodically check on it's status. The background process should update some status variable on a regular basis and store it's data in the cache or session when complete. When it completes and the browser detects this (via AJAX), have the browser do a real postback (or get by changing location.href), pick up the saved data, and generate the page.
I have a process that can take a few minutes so I spin off a separate thread and send the result via ftp. If an error occures in the process I send myself an error message including the stack trace. You may want to consider sending the results via email or some other place then the browser and use a thread as well.