linux/poky.git/bitbake/lib/prserv, branch 1.7_M3

bitbake: lib: fix no newline at end of file

2014-07-04T08:28:36+00:00

Add a '\n' to the last line of the file to fix: No newline at end of file (Bitbake rev: 54f1359ed2e9d47980cd221b7b43ef56543fe06d) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: prserv/db: Avoid fsync() calls

2014-05-03T10:24:48+00:00

If the power were to fail, it doesn't matter to us much if the data makes it to disk or not, we'd have other problems. However an fsync() call on a multi build autobuilder is painful so lets avoid them. (Bitbake rev: 4eb2dc8048e2722d64d589f453df1ce6262c71b8) 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: serv/db: Don't use BEGIN/COMMIT

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

Since we don't support using multiple servers on the same database file, don't use the BEGIN/COMMIT syntax and allow writes to the database to work ~100 times faster with no transaction locking. (Bitbake rev: 42144a54979658f93fbbb43f7e271c1fff4d88ff) Signed-off-by: Richard Purdie

bitbake: serv/db: Take an excluside lock on the database

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

We only support one server using the database at a time so take an exclusive lock and avoid later lock overhead. (Bitbake rev: e3e39be6f2d063858c92971ce8ccd89c95d4f26d) Signed-off-by: Richard Purdie

bitbake: serv/db: Fix looping upon database locked issues

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

If the database is locked we will get an immediate error indicating so, there is no retry timeout. The looping code is therefore useless, the loop count is near instantly exceeded. Using a time based retry means we can wait a sensible time, then gracefully exit. (Bitbake rev: 9f9e6d87007ea87e62495705464f4232c996a165) Signed-off-by: Richard Purdie

bitbake: prserv: Allow 'table is locked' matching for retry loop

2013-08-30T16:53:26+00:00

Try and avoid errors like "ERROR: database table is locked: PRMAIN_nohist" by retrying if we see the string "is locked". (Bitbake rev: 1a175b51f80d13f747b653d29e9c0d2201b5109c) Signed-off-by: Richard Purdie