We have an ASP.Net web service the call to which, due to some bad design, often takes more than 20 minutes to return. We have changed every setting that we can think of, but no matter what we do, we always get a timeout after 20 minutes.
It happens that this web service is a BizTalk orchestration exposed as a web service, but I do not think that is relevant -- the error is an ASP.Net error.
There must be some setting we can change to increase the timeout to more than 20 minutes, but we've exhausted our knowledge. What setting are we missing?
EDIT: Among other setting, we have tried those detailed here: http://weblogs.asp.net/aghausman/archive/2009/02/20/prevent-request-timeout-in-asp-net.aspx, which includes httpRuntime executionTimeout, sessionState timeout and app pool idle timeout.
Thanks,
Jason
Sets the timeout to 60 minutes:
<system.web>
<httpRuntime executionTimeout="3600" />
</system.web>
For .NET 1.0 and 1.1. the default is 90 seconds. For 2.0+ is 110 seconds.
httpRuntime Element (ASP.NET Settings Schema)
Can I just confirm - BizTalk consumes this slow ASMX / WCF service and then re-publishes it (or aggregates this as part of an orch) and it is the consumer which is timing out?
Grasping at straws here, but can you change this consumer to use WCF?
If so, there are more knobs that you can tune
e.g. in the client Bindings
sendTimeout = "00:XX:00"
Also, have you investigated KeepAlives?
Related
I'm having issues with session timeout issues with a public facing site that is utilized by several clients that may have various "secured" browser configurations. In general we have the session timeout set for 15 mins within the web.config. However, they are getting a timeout within a min or within 30 seconds or so for every page postback. Within our environment and with some other clients they have no issues and the timeout occurs as expected. We are unable to access their systems and know very little about their infrastructure. The only thing I'm thinking is they may have configuration to disallow cookies or delete/wipe them every few seconds etc. Not sure....
I'm at a loss on what to look at as within our web.config we set our sessionstate as follows.
<sessionState allowCustomSqlDatabase="true" cookieless="UseCookies" mode="InProc" sqlConnectionString="somestring Integrated Security=SSPI;pooling=true;encrypt=true;trustservercertificate=true" timeout="15">
If someone has ideas on where to look.
I deployed one webservice which calls function which going take more than 5 -6 hours. I am using this webservice on my asp.net page and I am calling this webservice asynchronously. So how should I increase webservice time out?
If you are calling a function that takes 5-6 hours to complete, you may want to re-think your architecture. Would a user sit on the page and wait 5 or 6 hours for your process to finish? Probably not. Maybe you could have your web service set an indicator in a database, xml file or some other data store when it has completed. Then, in your asp.net page, you can click a button or complete some other action to check that indicator to see if the process has finished.
You need to chance the executionTimout in your Web.Config to something large like :
executionTimeout unit is in seconds.
<configuration>
<system.web>
<httpRuntime executionTimeout="21600"/>
</system.web>
</configuration>
If you are ok with all requests in your webservice having a long timeout, you can set
<httpRuntime executionTimeout="300"/>
Under
<system.web>
in your web.config, where 300 is your timeout in seconds
However, as DevSlick answers, you may want to reconsider your archetecture, web services aren't meant for long running tasks, you may want to create a console application that runs on a schedule.
I have an ASP.NET web application that I can't modify (I only have the binaries). This application connects to a web service and it seems like the connection is closed from the client side (my web app). I have increased the "executionTimeout" in the machine.config of the destination server but my web app seems to still stop after waiting for a while.
Is there a way to increase the timeout time for my web application by simply modifying the web.config? As I said... I can't modify the timeout in the code so my only option would be through config files.
Thanks!
Try if this would work for you.
Firstly, you need to increase the timeout of the executionTimeout attribute of the httpRuntime element. Note that this is mentioned in Seconds unlike the other timeout attributes like the Session timeout and others.
<httpRuntime
executionTimeout="36000"
And moreover, this attribute takes effect only when you set the debug attribute of the Compilation element to false. This is also specified in the MSDN link that you mentioned. Like,
<compilation
debug="false"
../>
But this works in conjunction with the Session timeout. Yes, if the session times out , then an error would be thrown. and it wouldn't wait for the executionTimeout value to take effect. so you also need to set the Session Timeout to a higher value. And note that this is in minutes. which would look like,
<sessionState
mode="InProc"
timeout="360"
...
/>
And note that all of this would be overriden by AppPool recycling process. so you need to set the Idle Timeout value of the Apppool that your website uses to atleast same / higher value than the session timeout.
I found it here http://www.eggheadcafe.com/community/aspnet/17/10111748/how-can-we-increase-the-t.aspx
The default timeout of web application is 90 seconds which is usually more than enough for general purpose use. It is important to note where the timeout is coming from. Is it from the page itself or something in the page that is causing it. In either case, it would appear that the "the page" is timing out.
I stumbled upon this question as my page was timing out too. Found out the exception was coming from SQL (read the the actual error) so it was really SQL problem. Once I knew it, I could easily fix it.
In web.config file
<binding name="endpointname" sendTimeout="00:3:00" />
This will update timeout property to 3 minutes
Authentication cookies seem to timeout after a short period of time (a day or so). I am using Forms Authentication and have the timeout="10080" with slidingExpiration="false" in the web.config. With that setting, the cookie should expire roughly 7 days after the user is successfully authenticated.
This worked as advertised with IIS6, but when I moved the site to IIS7, the cookie expires much quicker. I've confirmed this behavior on multiple machines with IE and Firefox, leading me to believe it's an IIS7 setting.
Is there a hidden setting that is IIS7 specific related to authentication? All other authentication types are disabled for the website, except for anonymous user tracking.
The authentication cookie is encrypted using the machineKey value from the local web.config or the global machine.config. If no such key is explicitly set, a key will be automatically generated, but it is not persisted to disk – hence, it will change whenever the application is restarted or "recycled" due to inactivity, and a new key will be created on the next hit.
Resolving the problem is as easy as adding a <machineKey> configuration section to web.config, or possibly (preferably?) to the machine.config on the server (untested):
<system.web>
...
<machineKey
validationKey="..."
decryptionKey="..."
validation="SHA1"
decryption="AES"/>
...
</system.web>
Google generate random machinekey for sites that can generate this section for you. If your application deals with confidential information, you might want to create the keys yourself, though.
My understanding is that cookies are expired by the consuming party - the browser, which means that IIS has no say in this
Set session state configured in IIS as
In Process
Use Cookies
Time out = your required time
Use hosting identity for impersonation
Also set EnableSessionState to true (which is default too)
And most importantly run the app pool in classic mode.
Hope your problem will solve.
First of all i must say that these "guidelines" are generic and not iis-7 exclusive.
In web.config under <system.web>
you either have <sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424" timeout="130" cookieless="false"/> (which requires the ASP.NET Session State Server service running on localhost)
or <sessionState mode="InProc" timeout="130" cookieless="false"/>.
The main difference is that in InProc that session state data are placed in the application process itself. In the other setting a different service is doing the storage, and you application just polls it to get the required data.
Having used both (as well as sql-server session state mode) the InProc is the least reliable but the fastest. The Sql-server is the most reliable and the slowest and the StateServer mode is somewhere in the middle being unreliable only in the case of a power/system failure. Having said that, i must say that for site with a low request count the performance penalty is negligible.
Now, my experience has shown that InProc is quite unpredictable on its stability; i used to have the same problem with you. I was able to extend the stability of the application by tweaking the settings of the application pool, i removed the problem altogether by switching to SessionState (which also allows to bring down the application and not lose session state data).
The reasons that you may suffer from application/session stability:
IIS and application pooling. Each virtul directory of a website is assigned to an application pool (by default to "DefaultAppPool") which has a series of settings amongst which you define the interval that the process is "recycled" - and as such preserve system resources. If you don't change the settings the application may trigger one of the criteria for the process recycler, which means that your application is busted
Antivirus.
In a ASP.NET application if the web.config (and any child .config files the application depends on) file is touched the application is restarted. Now there are cases where an antivirus program may touch the web.config file (say once a day?) and as such the application is restarted and session data is lost.
Bad configuration
Specifically for Forms Authentication the time-related settings and behavior always where dependent on the web-session with the auth-session being under the web-session.
What i don't know is if the Forms Authentication module depends only on Session domain or if it also places data in the application domain as well. If the second is the case then you may have to disable all recycling settings in the Application Pool as well as checking again configuration/antivirus and who stores the session data.
I recently had the same problem where my site was timing out every 20 minutes even though I set the session timeout to 2 hours. I found that it was because IIS worker process was timing out every 20 minutes: http://technet.microsoft.com/en-us/library/cc783089(WS.10).aspx
I'm very confused when it comes to what actually decides the session time-out.
The web app needs to allow for a 20 minute "idle time" before logging (or throwing) users out. I've tried different setting on both sessionState and Recycle worker processes in IIS. The time-out remains too short and, as far as my quit-n-dirty, primitive tests have shown, a bit random.
I read somewhere that the default time-out is 20 minutes, but in my app it appears to be closer to five. Are there any easy ways to change this? The app is running .NET 3.5 on IIS 6.
EDIT:
I just realized that the Entity Framework might have something to do with the problem, as the user content is held as a context in the entity framework. Is there any time limit for how long an entity is held?
The user will be logged out based on your Authentication settings in the web.config.
The Session timout will be set in your session tag in the web.config.
If they are different then you will see "interesting" results.
http://msdn.microsoft.com/en-us/library/ms972429.aspx
If you look in the web.config you can write some thing like this
<configuration>
<sessionstate timeout="20" />
</configuration>
and there you can set you timeout..
Use the sessionstate timeout. You do not want to use Recycle Worker, as this will recycle all sessions associated with that worker, every N minutes. It's a good idea to set Recycle Worker to a very high value if you are using the session variable.