Server Times (UTC) and Differences

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

Based off a requests from Stephen McConnell and Niclas Hedhman, I started
some tinkering with capturing/displaying server run times. Also, I tried
making it easier to do server comparisons (although I am not sure I achieved
that).

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.]

    http://lsd.student.utwente.nl/gump/servers.html

BTW: I've added a 'note' entry to the server records, so we can publicly
annotate comments like those above.

BTW: One bug, I included local timezone string in the format for UTC -- so
although it is showing UTC, it just displays wrong. This is fixed in CVS.

I created this page (differences log) in order to show entities with
different states on different servers.

    http://lsd.student.utwente.nl/gump/diffsLog.html

Further, on each project 'Server Links' page, we now see the time of run
(ok, server time, not per project).

    http://lsd.student.utwente.nl/gump/cocoon-2.1/cocoon/index.html#Servers

BTW: Same is-UTC-but-looks-like-local bug here, same fix.

I'm not closing this JIRA entry 'cos there is more work to do. I'd really
like to include the 'sequenceInState' (duration) in results, and perhaps
change this page to only show 'repeat offenders' -- differences on servers
over a period. I really ought show the exact CVS|SVN update time per entity
(not the server start time) but these are close enough for right now. Also
(from this page) remove those that differ only by pre-requisite failed ('cos
they are likely knock on issues).

Finally, I'd also really like to generate an "intelligent assistant" (we
have an automated rabid developer, I'd like an automated rabid Gumpmeister
;-). This ought take the information in these pages and creates a
'gumpmeister report' of purely salient details, picking the top problems,
showing some key differences, etc. A bit more time looking at these pages
and I might be ready to work on such. Perhaps I'll start a Wiki page on the
topic, in order to get Gumpmeister input.

regards,

Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com


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

Re: Server Times (UTC) and Differences

[Michael Davey <Mi...@coderage.org>]

Adam R. B. Jack wrote:

>Based off a requests from Stephen McConnell and Niclas Hedhman, I started
>some tinkering with capturing/displaying server run times. Also, I tried
>making it easier to do server comparisons (although I am not sure I achieved
>that).
>
>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.]
>
>    http://lsd.student.utwente.nl/gump/servers.html
>  
>
That's great!  Although... actually it is quite hard to read quickly.  
It would be great
to include the following:

 *  which host most recently finished a build and how long ago
 *  an estimate of which host will be next to finish a run and how soon
 *  an estimate of which host will be next to start a run and how soon

If someone really fancies a challenge, perhaps all three could be 
represented on a 24 hour
clock-face with "now" being north and using different colours to 
represent the start and
finish for the three hosts above? ;)

-- 
Michael


---------------------------------------------------------------------
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

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