gumpy.lock (was Re: Server Times (UTC) and Differences)

["Adam R. B. Jack" <aj...@trysybase.com>]

> This page lists all known servers (known to this profile) and in the
> (remote/downloaded) results.xml we now have strings that contain formatted
> start/end dates/times in local and UTC. This table ought show us our
> "windows of opportunity". [It shows me that DOTNOT and Hermes need taking
a
> look at, and that I bust Try regularly w/ documentation testing.]

Both DotNot and Hermes were stuck due to having a gumpy.lock file in
existence. I introduced the lock because if two Gumpys run at the same time
they fight terribly, and it explodes their memory usage to major bloat. That
said, ever since I've introduced the lock, we've had nothing but false
positives with it, each requiring manual cleanup. :(

The lock file is created by gumpy.py, and contains the PID of the process
that created it. In a 'finally' clause the file is removed. It remains
around (however) if the gumpy is killed, and there seems no Python (heck,
any language) way to ensure it is removed. As such, I'd like logic for
knowing when to ignore it and proceed. The obvious is to see if the process
is running, but I do not believe this is possible (portably) in Python.

I'll enter a JIRA entry to look into a real locking mechanism, one where the
OS cleans up upon process termination. [Probably something to do with
lockf().]

regards

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: gumpy.lock (was Re: Server Times (UTC) and Differences)

[Sam Ruby <ru...@apache.org>]

Adam R. B. Jack wrote:
> 
> I'll enter a JIRA entry to look into a real locking mechanism, one where the
> OS cleans up upon process termination. [Probably something to do with
> lockf().]

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65203

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org