The reliability of python threads
paddy3118 at netscape.net
Fri Jan 26 10:24:39 CET 2007
On 26 Jan, 09:05, n... at cus.cam.ac.uk (Nick Maclaren) wrote:
> In article <mailman.3176.1169771514.32031.python-l... at python.org>,s... at pobox.com writes:|>
> |> What makes you think Paddy indicated he wouldn't try to solve the problem?
> |> Here's what he wrote:
> |> What I'm proposing is that if, for example, a process stops running
> |> three times in a year at roughly three to four months intervals , and it
> |> should have stayed up; then restart the server sooner, at aa time of
> |> your choosing, whilst taking other measures to investicate the error.
> |> I see nothing wrong with trying to minimize the chances of a problem rearing
> |> its ugly head while at the same time trying to investigate its cause (and
> |> presumably solve it).
> No, nor do I, but look more closely. His quote makes it quite clear that
> he has got it firmly in his mind that this is a degradation problem, and
> so regular restarting will improve the reliability. Well, it could also
> be one where failure becomes LESS likely the longer the server stays up
> (i.e. the "settling down" problem).
If in the past year the settling down problem did not rear its head
when the server crashed after three to four months and was restarted,
then why not implement a regular , notified, downtime - whilst also
looking into the problem in more depth?
* You are already having to restart.
* restarts last for 3-4 months.
Why burden yourself with "Oh but it could fail once in three hours,
you've not prooved that it can't, we'll have to stop everything whilst
we do a thorough investigation. Is it Poisson? Is it 'settling down'?
Just wait whilst I prepare my next doctoral thesis... "
- Okay, the last was extreme. but cathartic :-)
> No problem is as hard to find as one where you are firmly convinced that
> it is somewhere other than where it is.
> Nick Maclaren.
More information about the Python-list