Re: Deadlock detection

Simon Riggs wrote:

> I think your proposal would work, but sounds fairly invasive. I'm
> concerned that if we interfere with the main line of processing we'll
> just introduce a new set of bugs that won't move us forwards. I would
> prefer a "watcher" approach, which doesn't directly interfere with the
> main line of processing and can be turned on/off. Perhaps it isn't
> possible?

It's not really invasive at all, you need an OutputStream implementation
(that is completely new code and separate from the rest of the driver)
and a small amount of setup code when first establishing the connection
to hook it in as the stream that's actually written to. The setup code
can be conditional. The rest of the driver doesn't change at all.

> How about a watcher thread that waits for main thread to respond, if no
> response within a timeout it wakes.

That could work. Note that there is no single "main thread", it's just
whatever application threads happen to be running queries. You would
need to arm the watchdog before any write or flush, and disarm it before
reading or returning to the client (via a normal return or an
exception). If the watchdog on a particular thread stays armed for more
than some period, you trigger a warning.

It might be tricky to get useful state out of the driver when that timer
goes off - you'll be in the wrong thread to get a useful stacktrace at
that point, I guess you'll have to go and abruptly close the underlying
socket to unblock the deadlocked query thread - which means you need to
have some way to correlate threads with sockets. And you kill the
connection by closing down the socket, obviously.

Seems like it would get a bit complicated..

-O