Re: Notifications - Mailing list pgsql-admin

From Donald Fraser
Subject Re: Notifications
Date
Msg-id 003301c4e438$8a304fe0$6464a8c0@DonAcer
Whole thread Raw
In response to Notifications  ("Donald Fraser" <postgres@kiwi-fraser.net>)
Responses Re: Notifications
List pgsql-admin
Hello again,
I had to rush off to a Christmas meal last night, hence the late reply....

Well today I looked extensively into the problem and discovered that the NOTIFY
messages are arriving outside the firewall.
I used psql which itself connected to the database with ssl and received its
own NOTIFY messages ok
.
Looking at our software, which is java, the problem lies in the implementation
of receiving NOTIFY messages. It uses a separate thread to check the input
stream of the socket for incoming data. The problem is related to ssl, the ssl
input stream (implemented by sun) does not appear to implement the
"available()" method, or at least that is what I'm seeing. According to the
documentation the default implementation always returns 0, where as the non-ssl
input stream definitely does implement the "available()" method which returns
the number of bytes that can be read from the input stream without blocking.
According to sun subclasses of InputStream should implemet the "available()"
method. Why didn't they just make it an abstract method forcing an
implementation - now our code is broken because of it!

This will not be an easy work around....

Thanks again for the input,
regards
Donald Fraser

----- Original Message -----
From: "Michael Fuhr" <mike@fuhr.org>
To: "Donald Fraser" <postgres@kiwi-fraser.net>
Cc: "[ADMIN]" <pgsql-admin@postgresql.org>
Sent: Thursday, December 16, 2004 6:54 PM
Subject: Re: [ADMIN] Notifications


> On Thu, Dec 16, 2004 at 05:44:09PM -0000, Donald Fraser wrote:
>>
>> Ok the problem is that outside our local network, and more precise on the
>> outside of our firewall, users do not receive NOTIFY messages. The exact
>> same software running on the local network, albeit not using SSL does
>> receive NOTIFY messages.
>
> As with the inside-vs-outside issue, SSL might be a red herring.
> It's curious that the same software behaves differently in different
> locations, but be careful not to use tunnel vision when investigating
> the cause.
>
> Is there *anything* else that's different between the systems whose
> connections work and those whose don't?
>
> Is it possible that the outside users are connecting to a different
> database server than the inside users?
>
> What OS are you using, what language, what database interface?  How
> are you checking for NOTIFY messages?
>
>> The problem is immediate, I can instanciate the sending of a NOTIFY message
>> from my own connection and I don't receive a return message yet users on
>> the local network do.
>
> Have you done simple tests with psql?  You'd probably have to issue
> a query before seeing the notification, but that should still tell
> you if the notification arrived at all.
>
>> Basically now that I know NOTIFY uses TCP and therefore "should" clearly
>> not be getting lost anywhere, I will do a lot more investigating into our
>> software as that is the most likely place for the proble!. It just seems a
>> bit strange that the same software can receive messages when on the local
>> network... The one thing I can be sure of is that it will be software! I
>> think the clue must be the setting up of SSL on our software....
>
> Again, beware of putting on blinders.  If the database connection
> is otherwise working then it would be strange if SSL configuration
> were causing the problem.  *Is* the connection otherwise working?
>
> --
> Michael Fuhr
> http://www.fuhr.org/~mfuhr/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>


pgsql-admin by date:

Previous
From: "Iain"
Date:
Subject: archive is compressed - any data will not be available
Next
From: Tom Lane
Date:
Subject: Re: archive is compressed - any data will not be available