I am facing an issue in my application that whenever user search for any data and then keep the application idle for like 15-20 mins, and then try to perform any operation on the application, then the application crashes. I am using simple DevEx Grid to show data and ahve details rows and Popup control for that grid.
I think the issue is with the sessions as my application was unable to maintain the session for that duration and due to which application crashes.
Moreover, i have not used any session variables into my application for data.
I cannot find the real cause for this error.
Can somebody help me for the same.
You could write client side javascript to make ajax calls to the server.
This will keep your session alive.
It allows you to have a short timeout at the server, and still a long time out for idle users.
Be sure to have a timeout though, in case your user is away for a hour, the page should log him out.
You can just set the session timeout in IIS to a really high number or minutes (like 1440 for an entire day). This setting is in the "Session State" area.
Another option would be to use Opera as your browser, and load the page once. After that, use Opera's "reload page every..." option to automatically reload the page every minute. This would extend the session forever.
Since you don't store anything useful in session, you should make a way it could reload without crashing. For this you need to anylyse when the crash happens and find a way to prevent the crash. either by initializing with a sane default or catch the exception and start fresh.
Related
Now that the use of one of my asp.net apps has gone up significantly, two odd problems are occurring that are very infrequent, and that I cannot reproduce.
I am at a loss as to how to debug and troubleshoot these problems.
Here are two examples:
One of my aspx pages resets a session state value to 0 on !IsPostBack (is true). However, one of my users at a specific location frequently comes to that page when it is not a postback and the session state value does not get reset on his laptop. (I am basing this statement on how the app subsequently behaves, not on running in debug mode) But the code works and the session state is reset on my laptop when I am sitting next to him running the app on my laptop using the same browser on the same internet connection at the same time. And when this user runs the app on his laptop from home where he has a better internet connection he does not have the problem as frequently.
One of the aspx pages in my app does a server.transfer to itself after running code that saves data to a DB. Almost all the time after the server.transfer the textboxes contain their default value (as they should since !isPostback==True), but about 1% of the time the textboxes contain the previous value. I know that there has been a roundtrip to the server because data has been saved. This problem occurs on the same pcs using the same browsers by the same users doing the same actions. So 99% of the time it works correctly, and 1% of the time they do the exact same thing and it does not work correctly.
How do I even start trying to figure out what is causing these problems if they seem to be occurring randomly?
I suspect that the quality of the internet connection is the issue because it is the one variable that is changing, but how does that info help me?
It's not like I can debug either of these problems by running my app in debug mode.
I am using Asp .Net 3.5, C# 3.5 and the app is run in IE 6-8. (IE 8 in compatibility mode)
I would add logging to code where the problem is occurring. Then inform the users who are having the problem to try and note the time when they run into the issue. Once you have the logs and an approximate time, you can go in and pour over these logs to see if anything points you in the right direction. I would also look at your IIS and Event Logs on the server.
You can install Firefox Throttle plugin to simulate slow connections. Lot's of things can happen in ASP.NET with slow page loads. If the page isn't loaded fully but items are clickable ASP.NET can get really upset with event validation...etc
Also, I encourage you to start logging and tracing the problem areas in your application. You can then correlate that with the IIS request logs and get a fairly accurate picture of whats's happening when.
It seems like you're having problems with Session State. By default, ASP.NET uses InProc session state mode which uses server memory to store values. In many occasions, this can be lost or reset (app pool recycled). Switching to SQLServer Session State might help you solve the issue.
I have some code that pulls data from SQL DB, then loops through the records to generate a string, which will eventually be written to a text file.
The code runs fine on my local, from VS, but on the live server, after about a minute and half, I get "No Data Received" error (chrome). The code stops in middle of looping through the DataTable. Hosting support said "The connection was reset" error was thrown.
I"m not sure if this is a timeout issue or what. I've set the executionTimeout in my web.config (with debug = false) and it didn't seem to help. I also checked the Server.ScriptTimeout property, and it does match the executionTimeout value set in the web.config.
Additionally, a timeout would normally give "Page not available" message.
Any suggestions are appreciated.
after about a minute and half
There's your problem. This is a web application? A minute and a half is a very long time for a web application to respond to a request. Long enough that it's not really worth engaging in various trickery to make it kind of sort of work.
You'll want to offload this process to be more asynchronous with the web application itself. The nature of web applications is that they should receive a request and respond in a timely manner. What you have here is a long-running process which can't respond in a timely manner. The web application can facilitate interactions with the data, but shouldn't directly handle the processing thereof in the request/response directly.
How does the web application interact with the process? Does it just start it, or does it provide information for the process to begin? I would recommend that the process itself be handled by something like a Windows Service or perhaps a Console Application. The more de-coupled from the web application, the better. Now, since I don't know anything about the process itself, I'm making a few assumptions about its behavior...
The web application can receive a request to start the process, along with any information needed for the process. It can store this in a database with a status value (pending, queued, etc.) and then respond to the user (in a timely manner) that the request has been received and the process has been queued. The web application can have a page which checks the status so that the user can see how the process is doing (if it's started, how many records it's gone through, etc.).
The offline application (Windows Service, et al) would just monitor that database for newly-queued data to be processed. When it sees it, it updates the status (running, processing, etc.) and provides any relevant feedback during the process (number of records processed, etc.) by updating that data. So the offline application and the web application are both interacting with the same data, but not in a manner which blocks the thread of the web application and prevents a response to the user.
When the process is finished, the status is again updated. The web application can show that it's finished and provide a link to download the results. The offline process could even perhaps send an email to the user when it's done, or maybe the web application can have some kind of notification system (I'm picturing the little notification icons in Facebook) which would alert the user to new activity.
This way the thread isn't blocked, the user can continue to interact with the application (if there's even anything with which to interact), etc. And you get other added benefits, too. For example, results of the process are thus saved in the database and automatically historically tracked.
It sounds like it's the browser that's timing out waiting for a response, not on the server. You can't control what the browser has set for this. What you can do is send a response of some kind to the browser, so that it knows you're still around and haven't crashed in some way.
For this to work, you can't wait until you finish building the entire string. You need to re-think your code so that instead of appending to a string, you are writing each addition to an output stream. This has the added advantage of being a much more efficient way to create your text file. For purposes keeping the browser alive, you can write out anything, as long as some data is coming back for the browser to read. Html comments can work for this. You also need to periodically flush your response stream, so that your data isn't sitting buffered on your web server. Otherwise you might still timeout.
Of course, the real solution here is to re-think your design, such that your operation doesn't take 90 seconds plus in the first place. But until you can do that, hopefully this is helpful.
it does sound like a timeout, Could you try and return the information via a View, this would certainly speed things up.(if possible).
When i had this error, i was able to resolve it by adding in the Web.config file:
<system.web>
<httpRuntime executionTimeout="600" maxRequestLength="51200" />
</system.web>
I'm a newbie in ASP and I've encountered worst developer nightmare: I've received fired worker huge ASP.NET project and I must make some changes on it. One of the changes is to prevent opening same site few times on one Active Directory login (different tabs, browsers, etc...)
As I've noticed that app is using session. Any ideas to use session to prevent multiple instances of the same site?
Here is an idea. Use a hidden field with GUID which would be randomly generated by server for each page load. When a request comes to the server it checks if GUID coming is what was generated last time. If it is different or empty (while session is alive) - redirect to some page saying access denied (no new GUID here). If it is correct, serve requested page. Small problem with this would be that if someone closes browser and reopens it he/she would get access denied when trying to use your app again. To minimize that you need to lower session timeout to 1 minute and use AJAX asp:Timer to keep session alive. Remember to exclude keep alive calls (and any other AJAX calls) out of GUID generation/verification pipeline. Of course end of session resets the process. Also it would be good to encourage users to properly log out.
This is relatively simple solution to implement although it is weaker in level of protection than permanent connection. Should be enough for non-technical end users though - depends on your "audience". But even for someone who knows about the mechanism, it would make using two "instances" of application quite difficult.
Do it if you really need to. Generally I agree with Marc that web apps should not be restricted this way. Maybe it is a requirement from someone who can be educated?
You just need to create a persistent connection from each page. If browser navigates from one page to another on a single tab then you'll have a single persistent connection at all times. If you get two parallel persistent connections from same user then the user opened a new tab.
In the master page footer add a script that does an ajax call to the server on a page that doesn't end its response (Like long polling). If another ajax call comes from same user while the last one is connected then this is a second tab.
You might want to checkout SignalR for persistent connection thing. It should be able to switch between web sockets or long polling based on browser capabilities.
You cannot prevent the url from being loaded in multiple browsers or tabs at one time, since this is a client-initiated process.
You could implement a persistent connnection (as suggested by Hasan Khan) to ensure that only one browser window can be active at a time. I would add on to that that when a new window is opened up, you could warn the user that they already have an open connection. If they choose to use the new connection, then you send a message down to the old connection (different browser, tab, etc) that will cause it to clear the browser window for that user.
i am having problems with an asp.net c# site whereby i am setting a session state object to true and then redirecting to another page that needs to check the value of the session state object and it is null.
Sometimes it is set correctly and other times is is simply null.
When i debug on my local machine it works perfectly every time. Only when i upload to my web server does this temperamental behaviour happen.
As it is based around the security of the site it is obviously important that the session data be valid and accurate every time.
Is session state data unreliable?
AFAIK its set to inproc, cookieless, 30 min timeout, vanilla installation of IIS.
Does anyone have any suggestions? Perhaps i need to thread.sleep inbetween the storing of the session data and the reading?
NB: the time between the write and the read is about 70ms.. ample time for the data to be written to RAM.....
No. It sounds like you are misusing session state. You can not rely on the user's session to be there. Your ASP.NET worker process could recycle, restarting the application and killing all sessions, or a file could change in your website, causing your application to restart and flushing all sessions, cookies could get flushed on the client, timeouts could happen, etc.
So you have to provide for all of these scenarios with Session State. Try to avoid using session state for things like this. If you're setting access inside your session state and you don't know exactly how it works, you could be opening your site up for a lot of security risks.
Everything point to a web farm. If you have different web servers on the production environment serving your application you would experiment this behavior.
I don't find any other explanation for this "WORKS ON MY MACHINE!"
I don't have an answer for your particular problem, but Claudio my be on to something.
What I have to say is that using session for security is so 90's. Literally.
FormsAuthentication was developed to replace that technique and does quite a fine job.
You should only rely upon session for trivial concerns that are easily recoverable.
Security is not one of those.
If the session state is lost, typically that's because your process either recycles or fails. I would never "rely" on the session state between pages. Instead you might want to try to persist data between pages some other way. Perhaps passing the information via form variables or saving the data in the database.
ASP.NET Profiles are a preferred way to save this sort of information. You might want to read ASP.NET State Management Recommendations.
One of the problems I have come across having complex tasks on the browser is with automatic timeouts.
Currently our site has a sliding expiration of 30 minutes. Normally, this isn't a problem because we use asp.net and most of the time the users update one or two fields and then submit the form. This obviously keeps the session active. I have struggled with how to handle this with significantly more complex forms/user interaction where there are few if no round trips to the server.
Now users can view reports, type emails etc. on our site, and I am struggling with how to keep their session active while they're actually using browser but they are not actively posting information back. I would dispense with the sliding expiration, but it's a requirement, so I am stuck with it. Most of our users are outside of the organization, so I can't use any form of SSO.
Does anyone have an elegant solution (I'll even go for an ugly one if it works), or am I out of luck?
Have the browser ping the server via Ajax periodically to keep the session alive. Most sites do something useful in this ping, like save a draft of the user's submission.
We recently went through this in my organization. Although it is not the best solution, and hitting the right session across multiple browser windows is rough, we put a countdown timer on our page, included a button that just went back and hit the server to restart the session, and also provided the user with a JavaScript popup (the user's favorite part of the solution) with a message saying that the session was, say, five minutes from timing out and to hit the "OK" button to restart. Then the button would hit the server to restart the session, restart the timer on the base page, close the popup and the base page didn't need to be refreshed at all.
erickson is on the the right track.
On the areas of the site that are prone to session-timeout due to "complex forms/user interaction where there are few if no round trips to the server", you can place a keepalive control to keep pinging the server, thus keeping the session alive.
Here is a sample control that you can use, or use as a basis for coding your own.
Ah, the age old problem of not wanting to increase the session time because of higher memory usage.
One answer is to also set a cookie that expires after more like a day that will tell the system to still remember the user. That's what eBay does, among others.