linux/poky.git/bitbake/lib/prserv, branch 1.5_M5.rc7

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

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

bitbake: serv.py: Fix hang when spawned dynamically with bitbake

2013-08-27T23:25:56+00:00

The PRServer has the possibility to hang indefinitely blocking on a semaphore processing a xmlrpc request to send an event back to the main bitbake instance. This was observed during a "bitbake -e" on a heavily loaded machine and the main bitbake instance and cooker exited before the PRServer emitted its first log. The stack trace is provided below as to show what happens every time a logger.info() is executed in the PRServer. Not only does it write to the stream handler but it also tries to send the event to the main event processor. self._notempty.acquire() self.queue.put(event) _ui_handlers[h].event.send(event) fire_ui_handlers(event, d) fire(record, None) self.emit(record) hdlr.handle(record) self.callHandlers(record) self.handle(record) self._log(INFO, msg, args, **kwargs) (self.dbfile, self.host, self.port, str(os.getpid()))) self.work_forever() pid = self.daemonize() self.prserv.start() singleton.start() self.prhost = prserv.serv.auto_start(self.data) cooker.pre_serve() bb.cooker.server_main(self.cooker, self.main) self.run() code = process_obj._bootstrap() self._popen = Popen(self) self.serverImpl.start() server.detach() server = start_server(servermodule, configParams, configuration) ret = main() It was never intended for the PRServer to send its logs anywhere but its own log file. The event processing is an artifact of how the PRServer was forked and it inherits the event log handlers. The simple fix is to clean up and purge all the log handlers after the fork() but before doing any of the typical PRServer work or logging. (Bitbake rev: 972bc43e6d5b1207b944b3baa8f9805adb35dda7) Signed-off-by: Jason Wessel Signed-off-by: Richard Purdie