Package manager is failing with "no such table: task"

Got the error in another place. I used an initial script and the hardy large ami.

==> /var/log/landscape/monitor.log <==
2009-08-20 21:17:00,864 ERROR [MainThread] Error running event handler landscape.monitor.packagemonitor.PackageMonitor._resynchronize() for event type 'resynchronize' with args () {}.
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/landscape/reactor.py", line 78, in fire
    results.append(handler(*args, **kwargs))
  File "/usr/lib/python2.5/site-packages/landscape/monitor/packagemonitor.py", line 85, in _resynchronize
    {"type" : "resynchronize"})
  File "/usr/lib/python2.5/site-packages/landscape/package/store.py", line 34, in inner
    result = method(self, cursor, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/landscape/package/store.py", line 280, in add_task
    "VALUES (?,?,?)", (queue, time.time(), buffer(data)))
OperationalError: no such table: task

I've found the problem: it's a bug in sqlite itself (either the bindings or sqlite). See the attached script: running "rm /tmp/1; python 1.py & python 1.py &" a couple of times should reproduce the bug quite easily (the first select fails in one of the process). Uncommenting the previous select solves the bug.

This is ready to review in the attached branch. Running a new query after the table creation seems to fix the problem, and I can't reproduce the bug anymore.

Very good catch.

Just a minor non-blocking comment. I'm wondering if for extra-safety we should perform the same dummy select on the other tables as well, even though that is probably not strictly necessary as they are not used by the package manager process.

+1!

[1] I find it odd that one of the new blocks catches both (OperationalError, DatabaseError), and the other catches only OperationalError. Shouldn't they both catch the same exception.

[2] Additionally, a try: except: else is being used, which means that if by any chance a different exception is raised other than the ones that are being catched the cursor will not be closed. I would change that to try: (try: except: pass) finally: cursor.close() instead.

+1 with those changes done, or a good justification. :)

Sidnei: about your [1], the code checks for an invalid database file, and handles this case (as no functionality is broken). So I have to keep them.

Merged in r140.

Unfortunately the bug is still there. I've opted for a more radical approach, and made the PackageStore class lazy, that means it creates the connection only when some queries are actually being requested.

I real-world tested the attached branch and it seems to work, as times at which the packagemanager and the packagemonitor handle their messages are typically not close (while the the times at which they register themselves as plugins are).

I think we should push this fix to the various AMIs, as it is particularly relevant for cloud instances.

I've created bug #465846 to track the new issue Free has brought up.
Please direct comments and reviews there.