extras-buildsys ChangeLog,1.28,1.29

[Daniel Williams (dcbw)]

Author: dcbw

Update of /cvs/fedora/extras-buildsys
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv10323

Modified Files:
	ChangeLog 
Log Message:
2005-06-24  Dan Williams <dcbw at redhat.com>

    * Rework job database handling.  Only 1 thread now has access to
        the job database, the BuildMaster thread.  This should fix issues
        with database locking, timeouts, etc.  sqlite doesn't really like
        multiple threads, plus it doesn't have row locking, only table
        locking.

        So, when things want the BuildMaster to do something, they queue
        up a request and the BuildMaster gets around to it.  Once consequence
        of this change is that job UIDs are not known until the job gets
        added to the database, so we can no longer return the job's UID
        to the client enqueueing the job.

    * BuildClients are also in their own thread now so they don't block the
        BuildMaster.  There are interesting cases where clients can block
        the server while the server is reading data from the client, or if
        the client tracebacks in the middle of an SSL connection.  This should
        help keep the server more robust.  Operational latencies are also
        reduced by this change and the one to the BuildMaster.




Index: ChangeLog
===================================================================
RCS file: /cvs/fedora/extras-buildsys/ChangeLog,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- ChangeLog	24 Jun 2005 17:13:25 -0000	1.28
+++ ChangeLog	24 Jun 2005 17:24:21 -0000	1.29
@@ -1,5 +1,26 @@
 2005-06-24  Dan Williams <dcbw at redhat.com>
 
+    * Rework job database handling.  Only 1 thread now has access to
+        the job database, the BuildMaster thread.  This should fix issues
+        with database locking, timeouts, etc.  sqlite doesn't really like
+        multiple threads, plus it doesn't have row locking, only table
+        locking.
+
+        So, when things want the BuildMaster to do something, they queue
+        up a request and the BuildMaster gets around to it.  Once consequence
+        of this change is that job UIDs are not known until the job gets
+        added to the database, so we can no longer return the job's UID
+        to the client enqueueing the job.
+
+    * BuildClients are also in their own thread now so they don't block the
+        BuildMaster.  There are interesting cases where clients can block
+        the server while the server is reading data from the client, or if
+        the client tracebacks in the middle of an SSL connection.  This should
+        help keep the server more robust.  Operational latencies are also
+        reduced by this change and the one to the BuildMaster.
+
+2005-06-24  Dan Williams <dcbw at redhat.com>
+
     * common/CommonErrors.py
         - Try to trap actual error strings.  Does this actually work?