Hi Gerald, Concurrent dispatch / concurrent request handling can be set with the property WOAllowsConcurrentRequestHandling or by calling the application method setAllowsConcurrentRequestHandling(true). I am not sure what the current Wonder default it, it used to be false. If you do change this to true, you need to be sure that your app is thread safe first. Otherwise, the results might be worse that your current problems.
For the "How long does it take to process these updates and inserts?” I was asking about the time it takes the server to process each request, not the user perceived time (which I hope is that you meant but the 1.5/2/3 minutes below. It does sound like something is causing some requests to take a long time to run. If you are not using concurrent dispatch and you have a lot of users and few instances, 10 requests in a row x 3 seconds to process each will lead to the last request waiting for30 seconds. Adding more instances in one way of addressing this. Chuck From: Gerald Jones <[email protected]<mailto:[email protected]>> Date: Friday, January 29, 2016 at 5:18 PM To: Chuck Hill <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: Session Timeouts 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 [cid:[email protected]] #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 [cid:[email protected]] #5. DB server load is low - 1/28/2016 5:00AM to 1/29/2016 2:00PM HST [cid:[email protected]] Mahalo, Gerald From: Chuck Hill [mailto:[email protected]] Sent: Friday, January 29, 2016 11:18 AM To: Gerald Jones <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[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]
