Thread: Pgadmin III loses connection with remote database and then hangs for a long time.

I am using pgAdmin 1.12.1 oct 21 2010 rev-REL-1_12_1 from Martin
Pitt's PPA on ubuntu maverick.

Often when I connect to remote database the program seems to lose
connection to the database and when this happens it just locks up
tight with a blank screen. It stays locked up for a pretty long time
and then finally comes back with an error message saying it lost
connection. It makes no effort to retry the connection and I usually
quit it or kill it at that point.

Normally when it hangs up like that I fire off another instance and
reconnect to the same database to finish what I was doing.

The databases I am connecting to are either not fire walled or have a
port open for traffic coming from my workstation.

I am wondering if there is anything I can do about this issue.

Thanks.

On 05/26/2011 09:45 AM, Tim Uckun wrote:
> I am using pgAdmin 1.12.1 oct 21 2010 rev-REL-1_12_1 from Martin
> Pitt's PPA on ubuntu maverick.
> 
> Often when I connect to remote database the program seems to lose
> connection to the database and when this happens it just locks up
> tight with a blank screen. It stays locked up for a pretty long time
> and then finally comes back with an error message saying it lost
> connection. It makes no effort to retry the connection and I usually
> quit it or kill it at that point.
> 
> Normally when it hangs up like that I fire off another instance and
> reconnect to the same database to finish what I was doing.
> 
> The databases I am connecting to are either not fire walled or have a
> port open for traffic coming from my workstation.
> 

And no switch between them? Usually, this kind of issues happens because
of a faulty firewall or switch.


-- 
Guillaumehttp://www.postgresql.frhttp://dalibo.com

>
> And no switch between them? Usually, this kind of issues happens because
> of a faulty firewall or switch.

I am sure there are lots of switches between me and the database. I
live in New Zealand and the server is usually in the US usually a
linode or rackspace node but sometimes it's also an EC2 Node.

This happens no matter where the database is.  There are no port
forwards there is usually an iptables rule that says allow postgres
access from my IP.

From: Guillaume Lelarge

> On 05/26/2011 09:45 AM, Tim Uckun wrote:
>> I am using pgAdmin 1.12.1 oct 21 2010 rev-REL-1_12_1 from Martin
>> Pitt's PPA on ubuntu maverick.
>>
>> Often when I connect to remote database the program seems to lose
>> connection to the database and when this happens it just locks up
>> tight with a blank screen. It stays locked up for a pretty long time
>> and then finally comes back with an error message saying it lost
>> connection. It makes no effort to retry the connection and I usually
>> quit it or kill it at that point.
>>
>> Normally when it hangs up like that I fire off another instance and
>> reconnect to the same database to finish what I was doing.
>>
>> The databases I am connecting to are either not fire walled or have a
>> port open for traffic coming from my workstation.
>
> And no switch between them? Usually, this kind of issues happens
because
> of a faulty firewall or switch.

I have seen similar problems on routers and switches that were
overloaded or misconfigured. Adding memory, or just increasing the
number of buffers available might fix the problem.

Bob McConnell

On Sun, 2011-05-29 at 13:09 +1200, Tim Uckun wrote:
> >
> > And no switch between them? Usually, this kind of issues happens because
> > of a faulty firewall or switch.
> 
> I am sure there are lots of switches between me and the database. I
> live in New Zealand and the server is usually in the US usually a
> linode or rackspace node but sometimes it's also an EC2 Node.
> 
> This happens no matter where the database is.  There are no port
> forwards there is usually an iptables rule that says allow postgres
> access from my IP.
> 

You can play with the tcp parameters in postgresql.conf to make sure
your tcp line is alive.


-- 
Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com

>
> I have seen similar problems on routers and switches that were
> overloaded or misconfigured. Adding memory, or just increasing the
> number of buffers available might fix the problem.

My router is simply an ADSL modem, I have no control over the
multitude of routers that are in the way between my house and
rackspace or linode.  My router is probably not that tunable but I'll
take a look.

I should mention that none of my ssh sessions suffer from the same
issues. I can have an ssh session open for days if I want.

As an aside...

Why does losing the connection lock up the entire application? That's
the annoying bit, having to launch another instance of pgadmin because
the first one completely unusable and establishing a second
connection.

>
> You can play with the tcp parameters in postgresql.conf to make sure
> your tcp line is alive.

That's an idea. Thanks.

From: Tim Uckun

>> I have seen similar problems on routers and switches that were
>> overloaded or misconfigured. Adding memory, or just increasing the
>> number of buffers available might fix the problem.
>
> My router is simply an ADSL modem, I have no control over the
> multitude of routers that are in the way between my house and
> rackspace or linode.  My router is probably not that tunable but I'll
> take a look.

I didn't realize you were talking about Internet connections. Once you
go that route, most of the path quality is outside of your control. My
suggestion only applies where the entire path is inside your own domain.

> I should mention that none of my ssh sessions suffer from the same
> issues. I can have an ssh session open for days if I want.

Have you tried tunneling your database connection through an SSH
session, or a VPN? If that is a more reliable path, it might be worth
the effort to make use of it. As a side effect, it would also hide your
work from both curious and malicious outsiders.

> As an aside...
>
> Why does losing the connection lock up the entire application? That's
> the annoying bit, having to launch another instance of pgadmin because
> the first one completely unusable and establishing a second
> connection.

It may just be me, but this sounds like a bug. Have you looked at the
tracker to see if it has already been reported? Since it appears you can
reproduce it reliably, perhaps you should post it there so the
developers can take a closer look at it. If you go that route, I suggest
using Wireshark to capture one or more sessions that lock up the client
and attach the raw capture files onto the bug report. This will help
them identify the actual problem and insure the fix really works.

Bob McConnell

> It may just be me, but this sounds like a bug. Have you looked at the
> tracker to see if it has already been reported? Since it appears you can
> reproduce it reliably, perhaps you should post it there so the
> developers can take a closer look at it. If you go that route, I suggest
> using Wireshark to capture one or more sessions that lock up the client
> and attach the raw capture files onto the bug report. This will help
> them identify the actual problem and insure the fix really works.

I haven't done that because I thought I would post it here first and
see if somebody had similar experiences.

I can reproduce it fairly regularly although I have taken to logging
out of the remote sessions immediately after I am done to avoid the
problem. I'll install wireshark and see if I can get a capture
tomorrow.

To me the problem smells like a threading issue. The connection is
timing out and blocking the entire app and the gui locks up until the
timeout exceeds and the app is responsive again. Unfortunately the
timeout seems to be set to something really long.

From: Tim Uckun

>> It may just be me, but this sounds like a bug. Have you looked at the
>> tracker to see if it has already been reported? Since it appears you
can
>> reproduce it reliably, perhaps you should post it there so the
>> developers can take a closer look at it. If you go that route, I
suggest
>> using Wireshark to capture one or more sessions that lock up the
client
>> and attach the raw capture files onto the bug report. This will help
>> them identify the actual problem and insure the fix really works.
>
> I haven't done that because I thought I would post it here first and
> see if somebody had similar experiences.
>
> I can reproduce it fairly regularly although I have taken to logging
> out of the remote sessions immediately after I am done to avoid the
> problem. I'll install wireshark and see if I can get a capture
> tomorrow.
>
> To me the problem smells like a threading issue. The connection is
> timing out and blocking the entire app and the gui locks up until the
> timeout exceeds and the app is responsive again. Unfortunately the
> timeout seems to be set to something really long.

The default TCP connection timeout is around 3 1/2 minutes. This is left
over from the leased line and slow connection days when the protocol was
defined and has never been updated to match the reality of high speed
networks. This may be the timer it is waiting for. Some of the
MS-Windows network drivers in particular are notorious for locking up
the workstation while waiting for events that never happen. Losing a
remote shared drive you have mapped into often causes very similar
symptoms. But I am not one to speculate about the internals when I have
never looked at the code. I find it much better to report the symptoms
with as much supporting data as I can so the people that understand how
it works can do the diagnosis.

Bob McConnell

>
> The default TCP connection timeout is around 3 1/2 minutes. This is left
> over from the leased line and slow connection days when the protocol was
> defined and has never been updated to match the reality of high speed
> networks. This may be the timer it is waiting for. Some of the
> MS-Windows network drivers in particular are notorious for locking up
> the workstation while waiting for events that never happen. Losing a
> remote shared drive you have mapped into often causes very similar
> symptoms. But I am not one to speculate about the internals when I have
> never looked at the code. I find it much better to report the symptoms
> with as much supporting data as I can so the people that understand how
> it works can do the diagnosis.

I didn't mean to imply I had a definitive answer. That's just how it
looks like to me.  BTW I am on linux.

I experience this issue on a fairly regular basis.

I never have this problem using a locally available database.  It's only on remote databases.

It's very annoying when it does happen, as I find I basically have to kill the app and start over.

It seems to me like there is a firewall somewhere along the line that after some time of disuse, decides the session is
nolonger valid and no longer passes the data.
 

Now, the network connectivity aspect is totally out of my control, but, the pgadmin's response to the issue could be
better,for sure.
 

Regards,
Peter.





-----Original Message-----
From: pgadmin-support-owner@postgresql.org [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Tim Uckun
Sent: Wednesday, June 01, 2011 8:57 AM
To: Bob McConnell
Cc: pgadmin-support@postgresql.org
Subject: Re: [pgadmin-support] Pgadmin III loses connection with remote database and then hangs for a long time.

> It may just be me, but this sounds like a bug. Have you looked at the
> tracker to see if it has already been reported? Since it appears you can
> reproduce it reliably, perhaps you should post it there so the
> developers can take a closer look at it. If you go that route, I suggest
> using Wireshark to capture one or more sessions that lock up the client
> and attach the raw capture files onto the bug report. This will help
> them identify the actual problem and insure the fix really works.

I haven't done that because I thought I would post it here first and
see if somebody had similar experiences.

I can reproduce it fairly regularly although I have taken to logging
out of the remote sessions immediately after I am done to avoid the
problem. I'll install wireshark and see if I can get a capture
tomorrow.

To me the problem smells like a threading issue. The connection is
timing out and blocking the entire app and the gui locks up until the
timeout exceeds and the app is responsive again. Unfortunately the
timeout seems to be set to something really long.

-- 
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support