Re: Cheapest way to poll for notifications? & Driver improvement question re SSL and notify

Oliver Jowett wrote:
> Craig Ringer wrote:
>
>> === Why can't JDBC/SSL just test for data ready to read, anyway? ===
>
> Yeah, the SSL interface does suck :(
>
> I am wondering if we should look at a dedicated read thread per
> connection. In the past I avoided this because it doesn't scale to large
> numbers of connections, and there may be some overhead from context
> switching on I/O (though I haven't measured this). But between issues
> with notifications+SSL, and the increasing number of reports of I/O
> deadlocks, maybe we should look at it again.

That'll double the number of threads required for apps that already use
one thread per JDBC connection, though. Threads in Java are cheap, but
they're not free.

Are there likely to be circumstances where it's not acceptable for the
JDBC driver to require its own internal thread(s)? Where it _has_ to be
able to do its work on one thread?

Does the Pg JDBC driver have to be able to support green threads? If so,
it can't block in one thread and expect another thread's actions to
unblock the first thread, since they're both really the same OS thread
and when one blocks, they all block.

I'm a bit concerned that adding the requirement of one thread per JDBC
connection will do nasty things to some workloads that are currently
quite happy with the way things are. Ugly as the current SSL situation
and the handling of listen/notify is, it *is* a corner case and it does
have a decent workaround.

The other deadlocks you mention are more worrying, and I've seen
discussion here that suggests that some of the issues just aren't
fixable without the ability to read from a socket without blocking.
Consuming accumulating NOTICE messages so they don't fill up the read
buffer, for example.

I suspect that it'd be wise to make the use of one thread per connection
optional because of concerns like the above. I do think it might be
very, very nice to have, though.

I'll see if I can hack together a patch for the approach I was talking
about in my previous patch and see if it works.

Thinking less conservatively: If the java.nio API (JDK>=1.4) and
SSLEngine (JDK>=1.5) were used - for the JDBC4 driver only - then it'd
be possible to provide a pool of one or more threads dedicated to
handling the network chat for the driver's connection(s), by using the
connections in non-blocking mode via SelectableChannel:

http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/SelectableChannel.html
http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/Selector.html

then using SSLEngine on top to maintain the SSL state of each JDBC
connection. This would basically turn the JDBC driver connection/chat
handling into a state machine.

The popular SSLSocketChannel that hides much of the SSL gruesome-ness of
nio and SSLEngine use appears to be a SelectableChannel:

http://www.rmiproxy.com/ScalableSSL/javadoc/scalablessl/SSLSocketChannel.html

... so there are possibilities for hiding SSL gore behind that.

Of course, that's not exactly a trivial conversion (understatement of
the century award) even with SSLSocketChannel to hide much of the SSL
ugly-ness. It'd certainly be a nice way to keep connections separated
from threads working with those connections, though, and let apps use
anything from one thread for all work through to one thread per JDBC
connection. The Java 5 ExecutorService even provides a nice way to
configure and control that sort of thing.

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ExecutorService.html

So ... if I was to go frothing, drooling mad and start writing a new
JDBC driver now, that's probably how I'd do it - as a PostgreSQL
protocol state machine with an associated SelectableChannel for comms,
controlled via a Selector using an ExecutorService to manage the work.

--
Craig Ringer