I don't have an opinion on the default timeout. But in my experience
with other applications, you want to consciously make a choice about
what your timeout, based on your architecture and performance
requirements. You're much better off explicitly setting a timeout
that will cause your transaction to finish in a time a little longer
than you'd like and then either re-try or error out the transaction.
An alternate approach is is to set a quick timeout, one that is just
over the 99.?th percentile of transaction times, and then retry. (But
whatever you do, don't just retry endlessly, or you may end up with
this terrible growing mess of transactions retrying.)
In either case, it's a good idea to be monitoring the frequency of
timeouts, so if they increase over the baseline you can track down the
cause and fix it.
Just my $0.02.
On Thu, Oct 15, 2009 at 11:33 PM, Eric Lubow <email@example.com> wrote:
> So I ran the tests again twice with a huge timeout and it managed to run in
> just under 3 hours both times. So this issue is definitely related to the
> timeouts. It might be worth changing the default timeouts for Perl to match
> the infinite timeouts for Python. Thanks for the quick responses.