Re: Your session has timed out.
Re: Your session has timed out.
- Subject: Re: Your session has timed out.
- From: Chuck Hill <email@hidden>
- Date: Wed, 04 Jun 2003 11:41:07 -0700
At 09:54 AM 04/06/2003 -0600, Jevon Hills wrote:
>I'm experiencing what I hope is a Minor Problem.
>
>I have group of reports in a WO application. I can run each report
>with no issue on my local machine, using the prod database. As soon as
>I deploy to the production server (using the same database) All but
>one of the reports will run. The report that will not run is called
>"Dealer Report"
>
I assume by "does not run" you mean you get a session restoration error,
not a stack trace?
>I have done my best to figure out why this one is giving me grief now.
>This report ran until last week. I have taken a look at all of the
>settings in the JavaMonitor, and nothing seems amiss, but I'm missing
>something.
>
If you are getting a session restoration error (I'd guess about 15 - 30
seconds after starting the report) *and* you are running multiple instances
here is what is happening. The adaptor waits for a specific period of time
to get a response for a request. If the response does not come in that
time it assumes that the app will never respond and re-directs the request
to another instance. For direct actions this is no problem. For component
actions (which is almost certainly what you have) you will get a session
restoration error as the session in question does not exist on the new
instance. I'm guessing that this report is taking longer on the production
sever due either to new data having been added to the DB or the server
being more heavily loaded.
>Has any one else seen this? Can anyone offer directions to look at.
>
There are a number of ways to attack this.
1. Make your report run faster. This is, IMHO, the best solution. Simply
adding performance indexes to the DB and using batch faulting can often
accomplish this. You might also need to devise a more efficient reporting
process.
2. Increase the Connect and Receive timeouts in JavaMonitor so that the
report runs to completion before the adaptor gives up on the instance.
Keep in mind that unless you are concurrently dispatching requests, that
all other users will be blocked until the report finishes.
3. Use the WOLongResponsePage to generate the report. While this is a
somewhat elegant and appropriate solution it also implicitly makes your app
dispatch requests concurrently. This makes it very important that your app
is threadsafe and all the EOF objects are getting locked properly. You
will be wanting to test this!
4. Move the reporting to another reporting only application and increase
the Connect and Receive timeouts. This will prevent the session
restoration errors while not blocking users of the main application.
Chuck
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.