touch-packages team mailing list archive

[Pete Woods <1511553@xxxxxxxxxxxxxxxxxx>]

Well I'd also argue that level DB is a problem too, if it can't say "try
acquire lock up to some timeout". If it can only do an immediate "lock
could not be acquired" type failure, I guess it's not the end of the
world to try and get the lock every n milliseconds up to the timeout
instead.

-- 
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