Re: connection dropping continued

From: "Markus Wollny" <Markus(dot)Wollny(at)computec(dot)de>
To: "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>, "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
Cc: "Josh Endries" <jendries(at)pragmeta(dot)com>, <pgadmin-support(at)postgresql(dot)org>
Subject: Re: connection dropping continued
Date: 2004-02-18 00:00:06
Message-ID: 2266D0630E43BB4290742247C891057502B9D48B@dozer.computec.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-support

Hi!

-----Ursprüngliche Nachricht-----
Von: Andreas Pflug
Gesendet: Di 17.02.2004 21:10
An: Dave Page
Cc: Markus Wollny; Josh Endries; pgadmin-support(at)postgresql(dot)org
Betreff: Re: [pgadmin-support] connection dropping continued

Actually, it can be considered a BUG in the firewall, if it
disconnects
a tcpip session without sending the proper disconnect packet to
the
server, which assumes the connection being still valid and
sitting on
that open socket. Even web servers, routinely equipped with
timeout
functions themselves, would be delighted to be noticed about
disconnects
ASAP, to clean up services and save resources.

I don't know if it doesn't notify the server, I haven't noticed anything
there. As far as I know the server might be notified all right and the
connection closed - though surely the client doesn't receive any such
notification, otherwise it wouldn't sit there and wait for a response
from the server before finally throwing the timeout-errormessage. It's
really just a minor nag, so if the suggested workaround does indeed
involve digging arround in thread-concurrency issues, it's not worth it.
Sorry to have brought up the subject again, but I didn't find the
previous end of the same discussion and thus was not aware of the
complexity.

Regards

Markus

Browse pgadmin-support by date

  From Date Subject
Next Message Adam H.Pendleton 2004-02-18 02:22:00 Re: connection dropping continued
Previous Message Markus Wollny 2004-02-17 22:51:48 Re: connection dropping continued