Simon, I understand what you're saying and tend to agree with that philosophy. I think the issue has more to do with the undocumentedness (if thats not a word, it should be) of the Perl Thrift/Cassandra API in general. That is something I hope to change in the near future. Timeouts are definitely something I am going to make sure gets noted when I write up some code examples as well.
-e On Fri, Oct 16, 2009 at 9:36 AM, Simon Smith <[email protected]> wrote: > 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. > > Simon > > On Thu, Oct 15, 2009 at 11:33 PM, Eric Lubow <[email protected]> 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. > > -e >
