I am developing an application in asp.net 2.0, where i am products details from one site to another. But as there are thousands of products to upload, request time out occurs and the process does not complete.
Can any one help me or suggest me how i can avoid request timeout to occurs in between.
my application is in asp.net 2.0 and using InProc session state.
Thanks in advance.
i also set execution time out in web.config as follows:
<httpRuntime executionTimeout="3500" maxRequestLength="2097151" useFullyQualifiedRedirectUrl="false" minFreeThreads="8" minLocalRequestFreeThreads="4" appRequestQueueLimit="100" enableVersionHeader="true"/>
You can use sessionState. Similar question was answered here.
Related
When user login i am storing user_id in Session variable and on second page i am checking on page load if user_id exists then fine, otherwise redirect to sign in page but when i login and and redirected to next page after few seconds when i refresh page my session is null there and i am redirected to sign in page its happening in whole application i have tried all solutions but all in vain
Another thing is that application working fine on development server and also on local IIS in LAN but on live server this issue is occurring.
Kindly suggest solution, i am also defining session time out in minutes and mode in Proc in web.config.
Thanks in advance
If you are using InProc session state mode and multiple worker processes in the application pool then Session might expire automatically after few seconds as data loss can occur if different requests for the same session are served by different worker processes.
In my case, I am using InProc session state mode with Maximum Worker Process set to 4 hence session was expiring.
Setting Maximum Worker Process = 1 solved it.
You can add <httpRuntime delayNotificationTimeout=""/> in your web.config. see more
OR
Try this
<authentication mode="Forms">
<forms loginUrl="/loginurl" timeout="2880" />
</authentication>
try this in web.config
<configuration>
<system.web>
<sessionState mode="InProc" timeout="90"></sessionState>
</system.web>
</configuration>
One session issue I just ran into, which may help here, is that users from certain companies would have their sessions end fairly quickly but other users had no problem. After doing a lot of testing, I found that users connecting to the website from their office were having problems but the same user connecting from home had no problem.
Their company is setup to use a single IP (or set of IPs) for all out bound web requests. Well, this company had multiple IPs for out-site access and that IP changed (or could change) with each request. This would reset the session on my website and log them out.
I am still in the process of implementing a fix or a check for this so I can't give you a fool proof fix, but it is something to look into. This would explain what is happening to you.
Any chance you're using a cluster of servers? Network load balancing might reroute the client to a different server every time. If so, either the NLB has to be reconfigured to keep a client on a single server or set up session sharing.
Also check that the application pool doesn't have some obscene rule to recycle itself too often.
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
When I update an ASP.NET Website [note: it's not a Web Application] running on a customer server by overwriting it with the latest version it currently kicks all the users off.
I'd prefer to be able to deliver a new version of a site without kicking off users - is there a way to minimise the chance that users will get kicked off? [apart from the obvious one of waiting for a time of low-usage]
If I moved from InProc to Session State I guess this might do the trick - but is there any other method?
Chaning away from InProc Session State should help.
The problem now is that any time your app is reset in IIS (overwriting the web.config will cause a restart), the IIS Worker process restarts and clears your session info.
Check out this MSDN Page to read the limitations of In-Process Session State:
Session State - MSDN
I think additionally to what you are suggesting, it will be appropriate to display an "update in progress..." page instead of kicking off users. You can do that by changing your web.config file.
Session IDs are valid for the lifetime of the application pool, or until (I believe) 20 minutes following the last page request from the client in question. This is configurable in web.config:
<configuration>
<system.web>
<sessionState
cookieless="false"
timeout="20"
</sessionState>
</system.web>
</configuration>
If the application pool is recycled, files within the application are updated, etc, your session IDs will be invalidated. For this reason it is considered wise to deploy your site during off-peak hours.
Design your application to not rely on the existence of session state variables. Use cookies for authentication (or integrated auth) and check for session variables as you use them; reload them if they don't exist.
Here is my current question:
I'm guessing that my problem (described below) is being caused by ASP.NET worker processes being recycled, per the answers below—I'm using InProc sessions storage and don't see much chance of moving away, due to the restriction for other types of storage that all session objects be serializable. However, I can't figure out what would make the worker process be recycled as often as I'm seeing it—there wasn't any changing of the files in the app directory as far as I know, and the options in IIS seem to imply that the process would only be recycled every 1,740 minutes—which is much less frequent than the actual session loss. So, my question is now, what different cases can cause an ASP.NET worker process to be recycled?
Here is my original question:
I have a difficult-to-reproduce problem that occurs in my ASP.NET web application. The application has one main .aspx page that is loaded and initializes a number of session variables. This page uses the ASP.NET Ajax Sys.Net.WebRequest class to repeatedly access another .aspx page, which uses the session variables to make database queries and update the main page (the main page is never re-requested).
Occasionally, after a period of time using the page, causing successful HTTP requests where the session created in the main page properly carries over to the subpage, one of the requests seems to cause a new ASP.NET session to be created—all the session variables are lost (causing an exception to be thrown in my code), and a new session id is reported in the dynamically requested page. That means that suddenly, the main page is disconnected from the server—as far as the server is concerned, the user is no longer logged in.
I'm nearly positive it's not a session timeout—the timeout time is set to something ridiculous, the amount of time it takes to get this to happen is variable but is never long enough to cause the session to time out, and the constant Sys.Net.WebRequests should refresh the session timer.
So, what else could be happening that would cause the HTTP requests to lose contact with the ASP.NET session? I unfortunately haven't been sniffing network traffic when this has happened to me, or I would've checked if the ASP.NET session cookie has stuck around or not.
One solution would be to use a StateServer, rather than InProc session management.
Lots of things can cause the session state to be lost:
Editing Web.Config
IIS resetting
etc.
If the session state is important to your app then use either SQL state management, or the State Server which ships with ASP. NET.
Cheers,
RB.
We had problems of Session when we did migrating the AnkerEx application to the
new server. The new server had Microsoft Windows Server 2008 as operation system
and Microsoft Internet Information Services 7. Also in the server were installed
.NET Framework of versions 1.0.3705, 1.1.4322, 2.0.50727, 3.0 and 3.5.
For solving of this problem i have done enabling health monitoring for
application's Lifetime related events in ASP.NET 2.0. I had added to the web.config:
...
...
<system.web>
...
...
<healthMonitoring>
<rules>
<add name="Application Events"
eventName="Application Lifetime Events"
provider="EventLogProvider"
profile="Default"
minInterval="00:01:00" />
</rules>
</healthMonitoring>
...
...
It is help to us to check the AppDomain recycles. We can see it at our Event Viewer.
The link to more details is http://blogs.msdn.com/rahulso/archive/2006/04/13/575715.aspx
After I have done adding to web.config, the Event Viewer showed me that my
application is restarting every time when i do click to almost any link in my
application.
From the article of http://blogs.msdn.com/toddca/archive/2005/12/01/499144.aspx i
found out that ASP.NET has the new behavior - if we will do deleting, for example
a sub-directory of the application's root directory, then ASP.NET 2.0 will do the
restarting AppDomain.
The problem was in that that I had in the web.config the instruction:
...
<compilation debug="true" tempDirectory="c:\AnkerEx\Temporary ASP.NET files">
...
I.e. the ASP.NET did compiling of aspx pages in folder of my application root.
I think he created folders, may be and did removing some of them also. I removed
tempDirectory instruction and the application began work stable.
The worker process is probably cycling.
http://www.lattimore.id.au/2006/06/03/iis-dropping-sessions/
It could be caused by an unhandled exception in a background thread. It can cause your ASP.NET worker process to terminate. A new process is started very quickly so you don't actually notice it but all your sessions are lost.
Here is an article that explains it much better than I can: ASP.NET 2.0 Unhandled Exception Issues
quote:
An unhandled exception in a running ASP.NET 2.0 application will usually terminate the W3WP.exe process, and leave you with a very cryptic EventLog entry something like this:
"EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.1830, P3 42435be1, P4 app_web_ncsnb2-n, P5 0.0.0.0, P6 440a4082, P7 5, P8 1, P9 system.nullreferenceexception, P10 NIL."
Here is a Microsoft KB article that explains the same issue: KB911816 Unhandled exceptions cause ASP.NET-based applications to unexpectedly quit in the .NET Framework 2.0
My guess would be memory consumption - but, set up IIS to log recycles and you'll know for sure.