> +1 on fixing the problem of log rotation on windows.
> I don't like a solution that requires you to wait an
> arbitrary period for
> the snapshot to appear.
Yes, I see your concern. Assuming we stick to a rename operation, the
external process could simply wait for the expected file to appear (using,
say, FindFirstChangeNotification or ReadDirectoryChanges). Even a loop with
1 second sleeps before checking the file should work.
> Especially given that windows has a
> tendency to
> swap processes out to disc just because they haven't done anything
> recently. This means that if you run the logrotate at
> midnight you might
> easily spend the 5 seconds just swapping Zope back into
> memory. Given that
> you don't have a system 'kill' command so you'll need to run
> something zope
> specific to generate the equivalent, you might as well make
> it two-way to
> begin with and signal when the snapshot has been created.
Certainly that is doable, and it touches on a subject I (indirectly) brought
up here quite some time ago - a general notification mechanism so Zope can
let its "parent" know its status (eg, "starting", "running", etc). If we
can get a more generic notification scheme off the ground, it may make sense
to reuse that.
OTOH, it adds a level complexity where a slightly smarter "wait for file to
appear" loop in the external process may be all that is needed.
> I guess that the most obvious Windows equivalent of the kill
> command would > be to use win32event.CreateEvent() to create
> a named event. That can then be easily signalled from outside
> zope, but a thread inside zope would have
> to explicitly wait on the event (unless
> RegisterWaitForSingleObject could
> be used, but it isn't currently exposed in win32event).
Yep - that is exactly what I was thinking.
> Adding a thread to handle windows events to Zope could also
> be used to improve the communication when run as a service.
> Currently the zope process is terminated using
> TerminateProcess and it would be nicer if the service
> could generate a termination signal to give Zope a chance to shutdown
> cleanly and only resort to TerminateProcess if the clean shutdown was
Collector issues 1527 and 1533 provide startup/shutdown for Windows as it
exists on Linux, hopefully making that moot. As mentioned above, it has
been identified that Zope really could do with a generic notification
mechanism to improve the situation on all platforms.
I believe that if we keep the task small (ie, just log rotation), we can
come up with a fairly minimal patch which does the job perfectly. I'm
concerned that if we try and expand it into any kind of generic mechanism,
it simply will not happen.
I note that the only comments you made were on the mechanics of the
operation - which is good! I expected the scheme itself (ie, "rename to
.snapshot if possible") to be contentious.
Assuming no other serious objections come up, we will steam ahead!
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -