Aloha Chuck,
Thanks for your reply. #1. There are 5 to 7 pages to create a new dispatch record – time can vary from 1.5 – 2 minutes now with timeouts about 3.5 minutes a. Passenger Info b. Routing Info c. Miscellaneous d. Driver Info e. Billing Info f. Summary page with Create button g. Summary page with confirmation number #2. 20 seconds to 1 minute before System timeout message appears #3. Not sure, where is this parameter set? #4. Server load is low – 1/28/2016 5:00AM to 1/29/2016 2:00PM HST #5. DB server load is low - 1/28/2016 5:00AM to 1/29/2016 2:00PM HST Mahalo, Gerald From: Chuck Hill [mailto:[email protected]] Sent: Friday, January 29, 2016 11:18 AM To: Gerald Jones <[email protected]>; [email protected] Cc: [email protected] Subject: Re: Session Timeouts Hi Gerald, I suspect that what you are seeing is not a true session timeout. First, some questions. How long does it take to process these updates and inserts? How long after clicking submit does the session timeout message appear? Are you running with concurrent dispatch enabled? How loaded is the server? How loaded is the database? By default, the woadaptor will only wait for 15 seconds to get a response from the application. If it has not gotten a response in that time, it will send the request to a different instance. This is fine for session-less direct action but is not when a session is being used — as is the case with component actions (/wo/ in the url). Sessions don’t migrate between instances by default so the new instance is not able to obtain the session. It assumes that this is because the session has expired, rather than the request is from a different instance, which is why you see that slightly misleading message. If this is the problem, you have two options. You can increase the Receive Timeout in JavaMonitor to allow for enough time to process the request. This is the quick and easy solution. The other option is to optimize your application or environment so that it does not take so long to process a request. This is usually the better long term option, and also results in a better user experience. You could also look at Ramsey’s portable sessions framework (I completely forget the real name), but I would optimize first. The broken pipe message just means that when the app finally got around to sending the response back, the browser was no longer listening (it has a response from an instance that return the session timeout message. The broken pipe message is a symptom of the problem, not the problem itself. Chuck From: <[email protected] <mailto:[email protected]> > on behalf of Gerald Jones <[email protected] <mailto:[email protected]> > Date: Friday, January 29, 2016 at 1:42 AM To: "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> > Cc: "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> > Subject: Session Timeouts Our dispatchers are experiencing “Session Time Outs” after inserting or updating dispatch record. The time out occurs when the submit button is click to save the dispatch record. The application server log shows the following warning: WARN NSLog - <WOWorkerThread id=15 socket=Socket[addr=/127.0.0.1,port=xxxxx,localport=xxxx]> Exception while sending response: java.net.SocketException: Broken pipe Any ideas as to what is causing the problem and what can be done to resolve? The problem is random and lately has become more frequent. Mahalo, Gerald
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
