touch-packages team mailing list archive

[Pete Woods <1511553@xxxxxxxxxxxxxxxxxx>]

The way DBus handles this is very basic. It queues up the requests to
the name. So you'll have to release the name before you close the
database. I might suggest you could make your service wait to acquire a
database lock up to a certain timeout on startup. This would mean that
the second instance of your process that gets spawned waits until the
first instance has finished messing with the db.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to thumbnailer in Ubuntu.
https://bugs.launchpad.net/bugs/1511553

Title:
  Crash in queueRequest

Status in thumbnailer package in Ubuntu:
  Confirmed

Bug description:
  https://errors.ubuntu.com/problem/fa22f0b18ff6dc949c4cdf768f32121d64a83b8d

  We hit this occasionally, but not very often. I suspect it is because
  of the way we shut down: we destroy the thumbnailer instance before
  the dbus interface so we don't hit the race condition where one
  instance of the service still has the database lock while a second
  instance of the service is activated by a new incoming request. But,
  destroying the thumbnailer first means that, if a request arrives at
  just the right time, the dbu sinterface fires the request at the
  already-destroyed thumbnailer.

  I recently hit a whole slew of issues in a test that destroyed the
  thumbnailer and dbus interface (in that order) while there were still
  requests sitting in the scheduler and thread pools, and fixed a bunch
  of these issues (see the request-cancellation branch.) In effect, via
  the handler class that calls back into the thumbnailer and the
  closures that sit in the thread pools, we have created a circular
  dependency between the dbus interface and thumbnailer, which makes it
  impossible to shut down either without causing problems.

  I think the best solution would be to add a shutdown() method to the
  dbus interface that prevents new requests from firing. We also need
  some way to wait for all *received* (not just scheduled) requests to
  finish executing before physically shutting down.

  Does DBus have a way to say "I'm in the process of shutting down. Send
  the request that just arrived and that I can't process anymore to a
  new instance of the service"? Ideally, I would like to "close the
  gate" on incoming requests such that they are transparently re-sent,
  and then wait for all currently executing requests to finish
  processing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/thumbnailer/+bug/1511553/+subscriptions