[Duncan] > +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 > ignored. 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! Thanks, Mark. _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
