Re: Broken Pipe error using batik (SVG conversion)
Re: Broken Pipe error using batik (SVG conversion)
- Subject: Re: Broken Pipe error using batik (SVG conversion)
- From: Paul Lynch <email@hidden>
- Date: Wed, 14 Jun 2006 21:58:41 +0100
On 14 Jun 2006, at 21:42, Chuck Hill wrote:
On Jun 14, 2006, at 1:32 PM, Paul Lynch wrote:
On 14 Jun 2006, at 20:56, Robert Walker wrote:
I would say that Chuck's suggestions are ordered from "Best" to
"Worst." Use of the WOLongResponsePage definitely sounds like
the best solution in your case.
Agreed. WOLongResponsePage isn't very well documented - your only
option is to look at the example. Once you get the basic idea it
isn't hard to work with.
Generally speaking, IMHO, resorting to extending connection
timeouts is a "stop-gap" measure. Doing so may even reduce the
quality of the user experience. Whenever I know that a process
may take more than a few seconds to complete, I like to inform
the user, and provide some indication of progress (when
possible). Think of the spinning "beach-ball" or "hour glass."
It may be a nice way to inform the use that the system is busy,
but if it goes on too long the user will start to wonder is the
system is locked. They may even "Force Quit" (i.e. close the
browser window) if the system takes too long to respond.
I have had some experience of setting these timeouts. They can
give you some additional leeway in exceptional circumstances, but
the web server is also going to figure into the equation, and will
impose its own timeouts, making these settings pretty close to
useless for normal applications.
Which web server? I have had not problem setting these to at least
60 seconds when using Apache. Certainly it is a stop gap measure
and not a permanent solution, but I have found adjusting these
timeouts to be very useful.
I have used it with Apache (and probably IIS, but I forget). It was
some time ago, but Apache has a default timeout somewhere in the
30-120 seconds range, I believe (I haven't looked this up, and
corrections are welcome). You can change this if you want to, but I
don't consider it a very desirable way of fixing the problem.
Best practice would be to rewrite the app to use WOLongResponsePage,
or to tune the transactions so that each WO application has
reasonably consistent response times, and consider separating into
several different applications as an additional way of managing load
balancing.
In my case, we had a search transaction that could take anywhere from
5 to 120 seconds to run, and chose not to implement
WOLongResponsePage (I am sure we had some sort of reason for this,
but I doubt it was a good one).
In the grand scheme of things, I would consider adjusting timeouts to
be useful in the same general sense as pulling the plug on an
overheating server is useful - sometimes you have no choice, but you
will have to pay the piper.
Paul
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden