[Zope-Checkins] CVS: Zope/doc - CHANGES.txt:1.625.2.324
Update of /cvs-repository/Zope/doc In directory cvs.zope.org:/tmp/cvs-serv26940/doc Modified Files: Tag: Zope-2_7-branch CHANGES.txt Log Message: === Zope/doc/CHANGES.txt 1.625.2.323 => 1.625.2.324 === --- Zope/doc/CHANGES.txt:1.625.2.323Wed Apr 20 00:48:53 2005 +++ Zope/doc/CHANGES.txtWed Apr 20 01:22:02 2005 @@ -4,7 +4,7 @@ Change information for previous versions of Zope can be found in the file HISTORY.txt. - Zope 2.7.6 RC1 (2005/04/20) + Zope 2.7.6 b2 (2005/04/20) Bugs fixed ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] CVS: Zope/doc - CHANGES.txt:1.625.2.323
Update of /cvs-repository/Zope/doc In directory cvs.zope.org:/tmp/cvs-serv18673/doc Modified Files: Tag: Zope-2_7-branch CHANGES.txt Log Message: 2.7.6b2 === Zope/doc/CHANGES.txt 1.625.2.322 => 1.625.2.323 === --- Zope/doc/CHANGES.txt:1.625.2.322Wed Apr 13 08:07:57 2005 +++ Zope/doc/CHANGES.txtWed Apr 20 00:48:53 2005 @@ -4,6 +4,10 @@ Change information for previous versions of Zope can be found in the file HISTORY.txt. + Zope 2.7.6 RC1 (2005/04/20) + +Bugs fixed + Zope 2.7.6 b1 (2005/04/13) Bugs fixed ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] CVS: Zope/inst - versions.py:1.4.2.22
Update of /cvs-repository/Zope/inst In directory cvs.zope.org:/tmp/cvs-serv18673/inst Modified Files: Tag: Zope-2_7-branch versions.py Log Message: 2.7.6b2 === Zope/inst/versions.py 1.4.2.21 => 1.4.2.22 === --- Zope/inst/versions.py:1.4.2.21 Wed Apr 13 08:07:58 2005 +++ Zope/inst/versions.py Wed Apr 20 00:48:53 2005 @@ -4,4 +4,4 @@ # always start prerelease branches with '0' to avoid upgrade # issues in RPMs -VERSION_RELEASE_TAG = 'b1' +VERSION_RELEASE_TAG = 'b2' ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/lib/python/nt_svcutils/service.py Port from Zope 2.7 branch.
Log message for revision 30046:
Port from Zope 2.7 branch.
After consulting with Mark Hammond, removed the explicit calls to SvcStop().
That method gets invoked automatically by the services framework when a
stop request is generated. Calling it explicitly too caused the onStop()
method to get called multiple times. At least ZRS's Service subclasses
have onStop() methods that can't be called multiple times without raising
exceptions (they shut things down, and stuff like sockets go away the
first time onStop() gets called).
Changed:
U Zope/trunk/lib/python/nt_svcutils/service.py
-=-
Modified: Zope/trunk/lib/python/nt_svcutils/service.py
===
--- Zope/trunk/lib/python/nt_svcutils/service.py2005-04-19 15:05:49 UTC
(rev 30045)
+++ Zope/trunk/lib/python/nt_svcutils/service.py2005-04-19 15:52:29 UTC
(rev 30046)
@@ -161,7 +161,7 @@
# XXX why the test before the log message?
if self.backoff_interval > BACKOFF_INITIAL_INTERVAL:
self.info("created process")
-if not (self.run() and self.checkRestart()):
+if not (self.run() and self.checkRestart()):
break
self.ReportServiceStatus(win32service.SERVICE_STOP_PENDING)
@@ -206,7 +206,7 @@
win32api.TerminateProcess(self.hZope, 3)
self.ReportServiceStatus(win32service.SERVICE_STOP_PENDING)
-# Wait for the redirect thread - it should have died as the remote
+# Wait for the redirect thread - it should have died as the remote
# process terminated.
# As we are shutting down, we do the join with a little more care,
# reporting progress as we wait (even though we never will )
@@ -234,7 +234,6 @@
win32event.INFINITE)
if rc == win32event.WAIT_OBJECT_0:
# user sent a stop service request
-self.SvcStop()
keep_running = False
elif rc == win32event.WAIT_OBJECT_0 + 1:
# user did not send a service stop request, but
@@ -261,7 +260,6 @@
# this was an abormal shutdown.
if self.backoff_cumulative > BACKOFF_MAX:
self.error("restarting too frequently; quit")
-self.SvcStop()
return False
self.warning("sleep %s to avoid rapid restarts"
% self.backoff_interval)
@@ -276,7 +274,7 @@
self.backoff_cumulative += self.backoff_interval
self.backoff_interval *= 2
return True
-
+
def createProcessCaptureIO(self, cmd):
hInputRead, hInputWriteTemp = self.newPipe()
hOutReadTemp, hOutWrite = self.newPipe()
@@ -302,7 +300,7 @@
# problematic in general, but should work in the controlled
# circumstances of a service process.
create_flags = win32process.CREATE_NEW_CONSOLE
-info = win32process.CreateProcess(None, cmd, None, None, True,
+info = win32process.CreateProcess(None, cmd, None, None, True,
create_flags, None, None, si)
# (NOTE: these really aren't necessary for Python - they are closed
# as soon as they are collected)
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] CVS: Zope/lib/python/nt_svcutils - service.py:1.1.2.4
Update of /cvs-repository/Zope/lib/python/nt_svcutils
In directory cvs.zope.org:/tmp/cvs-serv16208/lib/python/nt_svcutils
Modified Files:
Tag: Zope-2_7-branch
service.py
Log Message:
After consulting with Mark Hammond, removed the explicit calls to SvcStop().
That method gets invoked automatically by the services framework when a
stop request is generated. Calling it explicitly too caused the onStop()
method to get called multiple times. At least ZRS's Service subclasses
have onStop() methods that can't be called multiple times without raising
exceptions (they shut things down, and stuff like sockets go away the
first time onStop() gets called).
=== Zope/lib/python/nt_svcutils/service.py 1.1.2.3 => 1.1.2.4 ===
--- Zope/lib/python/nt_svcutils/service.py:1.1.2.3 Wed Apr 13 21:47:48 2005
+++ Zope/lib/python/nt_svcutils/service.py Tue Apr 19 11:46:37 2005
@@ -161,7 +161,7 @@
# XXX why the test before the log message?
if self.backoff_interval > BACKOFF_INITIAL_INTERVAL:
self.info("created process")
-if not (self.run() and self.checkRestart()):
+if not (self.run() and self.checkRestart()):
break
self.ReportServiceStatus(win32service.SERVICE_STOP_PENDING)
@@ -206,7 +206,7 @@
win32api.TerminateProcess(self.hZope, 3)
self.ReportServiceStatus(win32service.SERVICE_STOP_PENDING)
-# Wait for the redirect thread - it should have died as the remote
+# Wait for the redirect thread - it should have died as the remote
# process terminated.
# As we are shutting down, we do the join with a little more care,
# reporting progress as we wait (even though we never will )
@@ -234,7 +234,6 @@
win32event.INFINITE)
if rc == win32event.WAIT_OBJECT_0:
# user sent a stop service request
-self.SvcStop()
keep_running = False
elif rc == win32event.WAIT_OBJECT_0 + 1:
# user did not send a service stop request, but
@@ -261,7 +260,6 @@
# this was an abormal shutdown.
if self.backoff_cumulative > BACKOFF_MAX:
self.error("restarting too frequently; quit")
-self.SvcStop()
return False
self.warning("sleep %s to avoid rapid restarts"
% self.backoff_interval)
@@ -276,7 +274,7 @@
self.backoff_cumulative += self.backoff_interval
self.backoff_interval *= 2
return True
-
+
def createProcessCaptureIO(self, cmd):
hInputRead, hInputWriteTemp = self.newPipe()
hOutReadTemp, hOutWrite = self.newPipe()
@@ -302,7 +300,7 @@
# problematic in general, but should work in the controlled
# circumstances of a service process.
create_flags = win32process.CREATE_NEW_CONSOLE
-info = win32process.CreateProcess(None, cmd, None, None, True,
+info = win32process.CreateProcess(None, cmd, None, None, True,
create_flags, None, None, si)
# (NOTE: these really aren't necessary for Python - they are closed
# as soon as they are collected)
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
Re: [EMAIL PROTECTED]: Re: [Zope-Checkins] CVS: Zope/lib/python/nt_svcutils - service.py:1.1.2.2]
[Mark Hammond]
> [For some reason Tim's original still hasn't arrived!]
You know, from my POV that statement is pretty mysterious, since you
seem to be replying to my email here .
[Tim Peters]
...
>> I'm trying to build a new ZRS release. Trying to stop the ZRS service
>> now "suddenly and for no reason at all" logs an error, because
>> I believe its onStop() method is getting called twice now, but used to
>> be called only once. That's no good for ZRS, because its onStop
>> method makes a connection to a special "shutdown port", and ZRS proper
>> responds by shutting ZRS down. The socket goes away along with it, so
>> trying to connect to the shutdown port a second time raises an
>> exception.
>>
>> I'm not entirely sure why this didn't used to happen. I'm guessing
>> that a stop request with the current code:
>>
>> 1. Triggers SvcStop, which calls onStop() and sets hWaitStop.
>> 2. Setting hWaitStop in turn triggers the WaitForMultipleObjects in run(),
>>and then that calls SvcStop again (which calls onStop() again).
>>
>> Anyway, is this bug or feature? If it's a feature, I can make the ZRS
>> subclass onStop() methods safe to call multiple times. It doesn't
>> _feel_ like a feature, though .
> From the sounds of things it is a bug .
>
> FYI, SvcStop is called by the (Python win32serviceutil) framework when an
> external request comes in to stop the service.
I think that's my #1 above, and I think that part works fine here.
The tracebacks I see have run() in the call stack, which is why I
guess #2 is doing SvcStop it a second time.
> However, a service can stop also stop by its own accord.
I don't think ZRS ever does that, and am not sure how I could write
code to do it. Does a Zope service ever decide to "stop by its own
accord"?
> The question, then, is under what cases should the onStop() calls be made? It
> sounds to me like you want it called only when that external request comes in.
Maybe. In the end, by whatever means a service gets shut down
(external, internal, whatever), I want to see the subclass onStop()
method called exactly once.
But that's mostly because that's what "used to happen" for the two
ZRS-related services, not because it's a Holy Principle I'd fight to
death to defend .
> Assuming that is the case, I believe both explicit calls to SvcStop() are
> bogus and can be removed completely. The report of
> SERVICE_STOP_PENDING will happen as soon as these functions return
> False. In both cases, it is not necessary to set hWaitStop as nothing is
> going
> to wait on it once these lines get hit. It seems we also don't want onStop()
> called at these times, so nothing the function does is necessary at those
> points.
>
> Also FYI, service.py is identical in both 2.7 and 2.8, so can be copied
> between them. I believe the diff you want is simply:
>
> RCS file: /cvs-repository/Zope/lib/python/nt_svcutils/Attic/service.py,v
> retrieving revision 1.1.2.3
> diff -u -r1.1.2.3 service.py
> --- service.py 14 Apr 2005 01:47:48 - 1.1.2.3
> +++ service.py 19 Apr 2005 04:48:18 -
> @@ -234,7 +234,6 @@
>win32event.INFINITE)
> if rc == win32event.WAIT_OBJECT_0:
> # user sent a stop service request
> -self.SvcStop()
> keep_running = False
> elif rc == win32event.WAIT_OBJECT_0 + 1:
> # user did not send a service stop request, but
> @@ -261,7 +260,6 @@
> # this was an abormal shutdown.
> if self.backoff_cumulative > BACKOFF_MAX:
> self.error("restarting too frequently; quit")
> -self.SvcStop()
> return False
> self.warning("sleep %s to avoid rapid restarts"
> % self.backoff_interval)
>
> That seems to work fine here.
Seems to work fine for the ZRS-related services too, although I didn't
get into the "restarting too frequently" branch. Thank you. If
nobody objects in the next 10 minutes, then, I'll check this in (and
port to Zope trunk (2.8) too).
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
