[CalendarServer-changes] [6841] CalendarServer/branches/users/glyph/db-reconnect/twext/enterprise/ adbapi2.py

[source_changes at macosforge.org]

Revision: 6841
          http://trac.macosforge.org/projects/calendarserver/changeset/6841
Author:   glyph at apple.com
Date:     2011-02-01 16:08:44 -0800 (Tue, 01 Feb 2011)
Log Message:
-----------
comment explaining the _real_ bug

Modified Paths:
--------------
    CalendarServer/branches/users/glyph/db-reconnect/twext/enterprise/adbapi2.py

Modified: CalendarServer/branches/users/glyph/db-reconnect/twext/enterprise/adbapi2.py
===================================================================
--- CalendarServer/branches/users/glyph/db-reconnect/twext/enterprise/adbapi2.py	2011-02-01 20:13:14 UTC (rev 6840)
+++ CalendarServer/branches/users/glyph/db-reconnect/twext/enterprise/adbapi2.py	2011-02-02 00:08:44 UTC (rev 6841)
@@ -281,6 +281,17 @@
 
 
     def _repoolAfter(self, d):
+        # FIXME: if abort() is called (say, by an HTTP connection terminating
+        # because the reactor is shutting down), the transaction will not
+        # immediately be moved to the 'stopped' list or removed from the 'busy'
+        # list; instead, it will be re-pooled only after the first abort()
+        # concludes, and stopService will sit in a loop calling abort() over and
+        # over again (and logging the traceback from _checkComplete()) until the
+        # thread actually doing the aborting finishes what it's doing.  This
+        # needs to be fixed to represent an intermediary state where completion
+        # has started and not stopped - note that this is *only* for interaction
+        # with stopService, there's no other legitimate cause for two abort()s
+        # to be called.
         def repool(result):
             self._pool.reclaim(self)
             return result
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20110201/2054fad4/attachment.html>