linux/poky.git/bitbake/lib/prserv/serv.py, branch dizzy-12.0.1

bitbake: prserv/serv: Ensure sync happens in the correct thread

2014-12-31T10:10:20+00:00

The sync/commit calls are happening in the submission thread which can race against the handler. The handler may start new transactions which then causes the submission thread to error with "cannot start a transaction within a transaction". The fix is to move the calls to the correct thread. (Bitbake rev: 08cf468ab751f4c6e4ffdab2d8e5d748f7698593) Signed-off-by: Richard Purdie

bitbake: prserv: don't wait until exit to sync

2014-12-31T10:10:20+00:00

In the commit 'prserv: Ensure data is committed', the PR server moved to only committing transactions to the database when the PR server is stopped. This improves performance, but it means that if the machine running the PR server loses power unexpectedly or if the PR server process gets SIGKILL, the uncommitted package revision data is lost. To fix this issue, sync the database periodically, once per 30 seconds by default, if it has been marked as dirty. To be safe, continue to sync the database at exit regardless of its status. (Bitbake rev: 973ac2cc63323ca9c3e916effa4765747db3564c) Signed-off-by: Ben Shelton Signed-off-by: Richard Purdie

bitbake: prserv/serv: Improve error message when prserver cannot bind to supplied host address

2014-09-29T11:08:48+00:00

If localhost resolves to a remote address (due to a misconfigured network), starting the pr server will fail without useful information. To reproduce, add ' localhost' to /etc/hosts and run 'bitbake -p'. The error message will be: ERROR: Timeout while attempting to communicate with bitbake server ERROR: Could not connect to server False: Running 'bitbake-prserv --host=localhost --port=0 --start' will fail with: error: [Errno 99] Cannot assign requested address Since these errors does not show the IP address of the attempted socket binding, this results in a lot of wasted time looking at firewall rules, etc. This patch results in the following error message if the socket binding fails: PR Server unable to bind to :0 (Bitbake rev: fae5914030bcf4c061c22fc61034c40c87b7121a) Signed-off-by: Konrad Scherer Signed-off-by: Richard Purdie

bitbake: prserv: Fix exit race issues

2014-03-30T09:10:36+00:00

We shouldn't immediately remove the pid file when stopping the server, if we do, this causes a traceback within the server itself which can then hang. Fix this by removing the stale pid file as the last thing we do. Also: * don't printing a new "waiting" line every 0.5 seconds. * make the loop more granular since the user can 'feel' the 0.5 seconds [YOCTO #5984] (Bitbake rev: 81f41a806aeddcc38992163557672e296bcbc967) Signed-off-by: Richard Purdie

bitbake: serv.py: Give pr-server up to 5 seconds to commit data

2013-11-18T17:19:11+00:00

The default value of 0.5 seconds before sending the pr-server a SIGTERM is not enough to guarantee that sqlite has committed all the pr data to the database. By polling the pid to see if it is still running, this allows the pr-server process to shutdown cleanly and finish the final pr data commit. (Bitbake rev: 22eec978e70794923c85689928c6be0cfe71cdcd) Signed-off-by: Konrad Scherer Signed-off-by: Richard Purdie

bitbake: prserv: Ensure data is committed

2013-09-08T09:51:56+00:00

In exclusive mode, we need to complete the transaction for writes to make it to the database. Therefore add sync calls to ensure this happens. Autocommit mode is significantly (100 times) slower so caching the data is of significant benefit. (Bitbake rev: 4e55f7821786a59c2cd7dbd8bfa2a22f5f196e99) Signed-off-by: Richard Purdie

bitbake: prserv/serv: Settle on two threads for optimal performance

2013-09-01T14:51:11+00:00

Using the threading mixin class resulted in large amounts of memory being used by the PR server for no good reason. Using a receiver thread and a thread to do the actual database operations on a single connection gives the same performance with a much saner memory overhead so switch to this. (Bitbake rev: e08455d5f3b8e96765942b9c3b9767c30650557d) Signed-off-by: Richard Purdie

bitbake: prserv/serv: Multithread the server

2013-08-28T23:13:22+00:00

This makes the PR server multithreaded and able to handle multiple connections at once which means its no longer a build bottle neck when serving one connection at a time. I've experimented and database connection for each thread seems to cause the least issues, pushing the contention for sqllite to handle itself. This means moving the db/table connection code into the actual function methods. It doesn't abstract well as a function since we need the db object around for the lifetime of the function as well as the table else we lose the connection. (Bitbake rev: bf9be2029b2bded5f532bdda4c38ae3dff5d1cf6) Signed-off-by: Richard Purdie

bitbake: prserv/db: Threading fixes

2013-08-28T23:13:22+00:00

Enabling threading for the PRServer causes a number of issues. Firstly is the obtuse error: sqlite3.InterfaceError: Error binding parameter 0 - probably unsupported type which is due to the class not being derived from object. See: http://docs.python.org/2/library/sqlite3.html#registering-an-adapter-callable Secondly, we want to enable multithreadded access to the database so we do this when we open it. This opens the way up to multithreading the PR server. (Bitbake rev: 5709efc2ff1e36529bd28f49cd093ccfa7abff7f) Signed-off-by: Richard Purdie

bitbake: serv.py: Fix regression from 972bc43e6d5b

2013-08-28T08:29:46+00:00

commit 972bc43e6d5b1207b944b3baa8f9805adb35dda7 (serv.py: Fix hang when spawned dynamically with bitbake) introduced a regression, because the wrong patch was submitted. The syntax was incorrect in the original patch. The logger iterator must be used with a call to getLogger(). [YOCTO #5059] (Bitbake rev: 85fed8acc3af3e15bf119db2f51c486a9de3646b) Signed-off-by: Jason Wessel Signed-off-by: Richard Purdie