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

On Mon, 21 Dec 2009 21:44:00 +0800, Craig Ringer
<craig(at)postnewspapers(dot)com(dot)au> wrote:
> (Re-sent, this time to the list)
>
> On 21/12/2009 9:13 PM, rsmogura(at)softperience(dot)pl wrote:
>
>> I haven't seen 1.4.2 JDK for ages :), but there is method
>> javax.net.ssl.SSLSocketFactory.createSocket that takes as the 1st
>> argument
>> plain socket, there is no need to "forgot" plain socket (and it can be
>> used, actually it's used for SSL communication with lazy handshake
>> FTPS/SMTPS...).
>
> That's how the PgJDBC driver works - it wraps an existing socket in an
> SSLSocket when SSL negotiation begins. Pg always begins with a plain
> text connection - it doesn't have a separate SSL port - so it has to
> begin with a plaintext connection and then request SSL negotiation using

> a plaintext message.
But I think we can leave plain socket somewhere to call available().

>> Unfortunatly plainSocket can have some available bytes, but
sslsoket.read
>> can return EOF. But this was i saw on SUN JDK is that read(new byte[0])
>> on
>> SSL socket causes process plain data.
>
> I'm pretty sure it also blocks if there's nothing to read. You'd have to

> run that in a background thread to force processing of any pending data
> by the SSL engine. If you're going to do that, you may as well just have

> a dedicated background thread to do all the reading from the socket...
It's not block, I tested on HTTPS.

I think the background thread, especially timer thread is better solution
then sending data to server.