Re: Cheapest way to poll for notifications? & Driver improvement question re SSL and notify
От | Craig Ringer |
---|---|
Тема | Re: Cheapest way to poll for notifications? & Driver improvement question re SSL and notify |
Дата | |
Msg-id | 4B2F1CEE.5080600@postnewspapers.com.au обсуждение исходный текст |
Ответ на | Re: Cheapest way to poll for notifications? & Driver improvement question re SSL and notify (Oliver Jowett <oliver@opencloud.com>) |
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления:
Предыдущее
От: Fred JanonДата:
Сообщение: Issue with the JDBC driver doing timezone conversions on "java.sql.Date"?
Следующее
От: Craig RingerДата:
Сообщение: Re: Cheapest way to poll for notifications? & Driver improvement question re SSL and notify