Printable View
Frank,
I'm getting the timeout error as well.
We let the Tornado application open and idle for 30 minutes, do a filter operation and the application crashes with the following MS SQL Server 2000 error.
Object reference not set to an instance of an object. an unhandled exception occurred during the execution of the current request.
We have other applications running on Tornado that do not appear to have this problem. What's with this?
Paul
It looks like it times out after 30 minutes. What is new about this timeout?
Frank
Frank,
I have no idea what you're talking about. "What's new with this timeout?" However, I need a resolution for this problem, and you appear to have some prior experience in this area. Paul
Paul,
Unlike local apps, Web is stateless and you neeed sessions to work. Set the various timeout values to cover your needs. A long timeout value will make your web app not sharable as you are holding the resources. Another way is store the state or pass the states inteh url in which ASP-db.Net does not do as none of them works well. Search for "session state" in MS site and you'll retrievce a lot of info. Meamwhile, use high timeout values to get by your problme. There is a write-up somewhere I made a long time ago about these values.
Frank
Hi Paul,
Just to add to what Frank said, you need to understand that the problem isn't with Tornado/ASP-db. It's merely an intentional "feature" of Microsoft's web technology. The idea goes like this...
1) A user hits a site for the first time - this causes them to get a unique session ID and set of session variables. If your code sets Session("xx")="hello", that "variable" will remain in "memory" while the session is "active".
2) If the user refreshes a page or does anything to make a trip to the server within the timeout period, then the 30 minute timer (in your case) "starts over" and they've got another 30 minutes before they must do something or timeout.
3) When 30 minutes expires with no activity, the theory is that the user is no longer "at their terminal". Remember, the server can't tell if you are "there" or if you even turned off your computer and headed out the door! So for "security", and for "resource utilization", it releases all those variables and your session is freed.
As has been mentioned in this thread (and in a thread from a couple days ago), there are tons of articles out there on workarounds. You could set your timeouts extremely long, or even have a page "refresh itself" so that it never times out, but from a security and from a resource point of view, that's usually not a good idea.
If you did this, a user could "log in", then walk away from their PC, and then, hours later, the midnight guard could come up and the session would still be logged in and he'd have full access to whatever your ID gave you. Face it, people forget to click "log out" buttons all the time, so we programmers have to do it for them.
Some government applications have timeout values of only 3 minutes! You snooze, you lose! No going to the bathroom without logging out!
Search Microsoft, and Google for ASP and .NET Application Timeout, and you'll see some interesting discussions on the subject with possible solutions. In any case, it's nothing we really have control over. It's a server side / IIS thing.
Take care,
John
Thanks John... could not expalain better than that.
At one time, there are efforts to make ASP-db sessionless using fat URL. This is the only choice I see that would work as the state storing approach always results in horror stories. But the justification was not there as few would leave the application alive for a long time for the security reasons.
Paul's case is that he is losing the FILTER in the tmeout. Actually ASP-db.Net preserved a lot of variables in the FAT URL but not filter. Seems like if FILTER is preserved then it would help a lot. Let me take a look whether there is any way to preserve that.
Paul, set the timeout value in the session state (Web.Config) to >20 minutes and see whether that woudl solve the problem (might be other variables lost).
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="50"
/>
Frank
I know what you are saying about session timeouts etc. But the problem for me is that this error is not trapped separately by Tornado. The "Object reference not set to an instance of an object. " can be have other causes. Is it not possible for Tornado to specifically trap the timeout error so that the user can be informed precisely what the problem is (ie, they have had the page opened for too long)?
Bob
Try the "Custom Error" trapping in the Web.Config file.
Frank
Also, goto Global.asax and put in your code for the "session end". The Tornado Login use this to detect the end of the user's session.
Frank
Hi
I have tried the session_end sub to trap the timeout error but the error I am getting on the filter page is not registering as a timeout.
I have changed the timeout to "1" in my webconfig to test the problem. I have also introduced a `try' `end try' error trap and the error is a system.NullReferenceException error. It is caused when the page session timeout is reached and is a result of using a dropdown list as a filter field. The following code will reproduce the problem. Copy it into a page and change the timeout setting in webconfig to "1". Wait for more than a minute and then click the submit button. You will get a
system.NullReferenceException error:
<%@ Page language = "vb" %>
<script runat="server">
Sub Page_Load(Source as Object, E as EventArgs)
Dim T As New tornado.z()
try
with T
.dbcommontables="index=shipper,look|val=1,2,3~Spee dy Express,United Package,Federal Shipping"
.dbQP = "U=33|Q=orders"
.dbFilterflds="field=shipvia|type=Selectbox|val=sh ipper|text=look"
.dbGridDisplayflds="shipname,shipcountry"
.dbDSN = "localhost;Northwind;sa;secret"
.dbDBType = "SQL"
.dbProvider="SQL"
.dbMode = "type=both|classic=true|FilterStart=true|indexFld= 0"
.dbstartup="filter"
.ASPdbNET()
end with
catch ex as exception
response.write("<br><br>general exception:" & ex.tostring())
end try
end sub
</script>
I haven't tried this with other page types yet.
Bob
where is the session_end code ?
what exactly you want to do?
Frank
Session end code from global.asax is:
sub Session_End(Sender As Object, E As EventArgs)
server.transfer("TimeoutErr.htm")
end sub
What I want to know is:
Why Tornado produces the
system.NullReferenceException error
instead of a timeout error on the filter page with the code I pasted which means that the above sub is never going to be called.
Error trapping is some work and has not much to do with Tornado which is just an application. Tornado trap internally some important errors related to the context like blankdb and invalid sqls. Other than that it works just like any other apps.
There are overall 2 types of error to be concerned with - Application_Error and Session_End. The Session_End event is meant for clearing up any objects or items that you have created for the session, you cannot interactively do anything like re-directing. When a session closes, it is usually because of a timeout in which the user has not requested anything from the server and the connection has
been lost. The Session_End event is not triggered by the user, so you cannot do anything with it. You can only redirect the user when the next session starts again.
It is easier to use global.asax instead of config.web as far as trapping error as you do not have to setup a virtual directory for the particular app. If you trap using try-catch within the aspx file - it'll also work. Do not use try-catch with application_error as it'll never get to the application_error.
Trap the application_error using ->
Sub Session_Start(Sender As Object, E As EventArgs)
Response.Write("Session is Starting...<br>")
Session.Timeout = 1
End Sub
Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
Response.Redirect("error.htm")
End Sub
FK
Frank
This doesn't explain why the filter page code I have posted only produces the `null' error when there is a dropdown filter field. I think it may be a bug.
Because the app timeout (all vars are gone) and the values are not init. Explain more if not the case.
Frank