Store/postgres inactivity disconnection

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Store/postgres inactivity disconnection

Charles Adams
Is there some way to maintain a connection to the database even over long periods of inactivity? Or increase the timeout value?
 
Since moving from Envy to Store, one of the things that I have a hard time assimilating is the need to 'connect-publish-disconnect' when interacting with Store/postgres. Its just one of those things that I never remember until it is too late. If I forget, I am reminded by the incredibly long time it takes to detect the disconnection and prompt me to reconnect. As I've reminded my co-workers, this presents an opportunity to get up and stretch, relax a bit and reflect on the work you've done and now want to publish.
 
But there are times when it becomes a nuisance. It would be nice if there were a way to tune the connection timeout or detection thereof.
 
Regards,
Charlie Adams   
Adventa Control Technologies, Inc.
3001 E. Plano Parkway, #100 
Plano, TX 75074-7422 
Office: 972.543.1688
FAX: 972.633.9317
http://www.adventact.com
[hidden email]
 
Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Reinout Heeck

That is not standard behavior, once connected you should stay connected.
Saving an image with an open connection should show a reconnect dialog at
image startup.

I suspect you need to talk to your network administrator, my guess is that
some firewall is closing those connections after inactivity. Once closed it
seem to have  really hard time to remember that ti did that too given the
timeout you complain about.

If your setup cannot be changed consider creating a process in your image that
does a trivial query (database time or version or so) every five minutes
using the Store db session.


HTH,

Reinout
-------


Charlie Adams wrote:

> Is there some way to maintain a connection to the database even over long
> periods of inactivity? Or increase the timeout value?
>
> Since moving from Envy to Store, one of the things that I have a hard time
> assimilating is the need to 'connect-publish-disconnect' when interacting
> with Store/postgres. Its just one of those things that I never remember
> until it is too late. If I forget, I am reminded by the incredibly long
> time it takes to detect the disconnection and prompt me to reconnect. As
> I've reminded my co-workers, this presents an opportunity to get up and
> stretch, relax a bit and reflect on the work you've done and now want to
> publish.
>
> But there are times when it becomes a nuisance. It would be nice if there
> were a way to tune the connection timeout or detection thereof.
>
> Regards,
> Charlie Adams
> Adventa Control Technologies, Inc.
> 3001 E. Plano Parkway, #100
> Plano, TX 75074-7422
> Office: 972.543.1688
> FAX: 972.633.9317
> http://www.adventact.com
> mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Charles A. Monteiro-2
In reply to this post by Charles Adams
Charlie:

I can't find any parameters of the bat in the respective conf files. It  
only happens when connects remotely. I wonder if this is "keep alive" type  
of thing on the socket, not sure maybe Bruce knows???

-Charles


On Thu, 19 Jan 2006 12:50:08 -0500, Charlie Adams <[hidden email]>  
wrote:

> Is there some way to maintain a connection to the database even over  
> long periods of inactivity? Or increase the timeout value?
>
> Since moving from Envy to Store, one of the things that I have a hard  
> time assimilating is the need to 'connect-publish-disconnect' when  
> interacting with Store/postgres. Its just one of those things that I  
> never remember until it is too late. If I forget, I am reminded by the  
> incredibly long time it takes to detect the disconnection and prompt me  
> to reconnect. As I've reminded my co-workers, this presents an  
> opportunity to get up and stretch, relax a bit and reflect on the work  
> you've done and now want to publish.
>
> But there are times when it becomes a nuisance. It would be nice if  
> there were a way to tune the connection timeout or detection thereof.
>
> Regards,
> Charlie Adams
> Adventa Control Technologies, Inc.
> 3001 E. Plano Parkway, #100
> Plano, TX 75074-7422
> Office: 972.543.1688
> FAX: 972.633.9317
> http://www.adventact.com
> mailto:[hidden email]



--
Charles A. Monteiro

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Charles A. Monteiro-2
In reply to this post by Reinout Heeck
Reinout:

I have seen this behavior from just about the beginning of time, for  
example if you open a connection to the public repository and do nothing  
for a while it will disconnect itself, there is some inactive connection  
settings , I sort of recall having asked Peter ? whose last name escapes  
me at the moment.

-Charles


On Thu, 19 Jan 2006 13:28:18 -0500, Reinout Heeck <[hidden email]> wrote:

>
> That is not standard behavior, once connected you should stay connected.
> Saving an image with an open connection should show a reconnect dialog at
> image startup.
>
> I suspect you need to talk to your network administrator, my guess is  
> that
> some firewall is closing those connections after inactivity. Once closed  
> it
> seem to have  really hard time to remember that ti did that too given the
> timeout you complain about.
>
> If your setup cannot be changed consider creating a process in your  
> image that
> does a trivial query (database time or version or so) every five minutes
> using the Store db session.
>
>
> HTH,
>
> Reinout
> -------
>
>
> Charlie Adams wrote:
>> Is there some way to maintain a connection to the database even over  
>> long
>> periods of inactivity? Or increase the timeout value?
>>
>> Since moving from Envy to Store, one of the things that I have a hard  
>> time
>> assimilating is the need to 'connect-publish-disconnect' when  
>> interacting
>> with Store/postgres. Its just one of those things that I never remember
>> until it is too late. If I forget, I am reminded by the incredibly long
>> time it takes to detect the disconnection and prompt me to reconnect. As
>> I've reminded my co-workers, this presents an opportunity to get up and
>> stretch, relax a bit and reflect on the work you've done and now want to
>> publish.
>>
>> But there are times when it becomes a nuisance. It would be nice if  
>> there
>> were a way to tune the connection timeout or detection thereof.
>>
>> Regards,
>> Charlie Adams
>> Adventa Control Technologies, Inc.
>> 3001 E. Plano Parkway, #100
>> Plano, TX 75074-7422
>> Office: 972.543.1688
>> FAX: 972.633.9317
>> http://www.adventact.com
>> mailto:[hidden email]



--
Charles A. Monteiro

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Alan Knight-2
I don't think this is behaviour related to Smalltalk. I have images that stay connected to my local postgres repository continuously for long periods of time.  So I suspect this is, as reported, a firewall or other intermediate software forcing it to time out, or just having an error, although it might also be postgres having an option to kill unused connections after some time. If a socket connection dies that way, I don't think there's a way of detecting that except by trying to send some communication.

At 01:46 PM 1/19/2006, Charles A. Monteiro wrote:

>Reinout:
>
>I have seen this behavior from just about the beginning of time, for  
>example if you open a connection to the public repository and do nothing  
>for a while it will disconnect itself, there is some inactive connection  
>settings , I sort of recall having asked Peter ? whose last name escapes  
>me at the moment.
>
>-Charles
>
>
>On Thu, 19 Jan 2006 13:28:18 -0500, Reinout Heeck <[hidden email]> wrote:
>
>>
>>That is not standard behavior, once connected you should stay connected.
>>Saving an image with an open connection should show a reconnect dialog at
>>image startup.
>>
>>I suspect you need to talk to your network administrator, my guess is  
>>that
>>some firewall is closing those connections after inactivity. Once closed  
>>it
>>seem to have  really hard time to remember that ti did that too given the
>>timeout you complain about.
>>
>>If your setup cannot be changed consider creating a process in your  
>>image that
>>does a trivial query (database time or version or so) every five minutes
>>using the Store db session.
>>
>>
>>HTH,
>>
>>Reinout
>>-------
>>
>>
>>Charlie Adams wrote:
>>>Is there some way to maintain a connection to the database even over  
>>>long
>>>periods of inactivity? Or increase the timeout value?
>>>
>>>Since moving from Envy to Store, one of the things that I have a hard  
>>>time
>>>assimilating is the need to 'connect-publish-disconnect' when  
>>>interacting
>>>with Store/postgres. Its just one of those things that I never remember
>>>until it is too late. If I forget, I am reminded by the incredibly long
>>>time it takes to detect the disconnection and prompt me to reconnect. As
>>>I've reminded my co-workers, this presents an opportunity to get up and
>>>stretch, relax a bit and reflect on the work you've done and now want to
>>>publish.
>>>
>>>But there are times when it becomes a nuisance. It would be nice if  
>>>there
>>>were a way to tune the connection timeout or detection thereof.
>>>
>>>Regards,
>>>Charlie Adams
>>>Adventa Control Technologies, Inc.
>>>3001 E. Plano Parkway, #100
>>>Plano, TX 75074-7422
>>>Office: 972.543.1688
>>>FAX: 972.633.9317
>>>http://www.adventact.com
>>>mailto:[hidden email]
>
>
>
>--
>Charles A. Monteiro

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Boris Popov, DeepCove Labs (SNN)
Alan Knight wrote:
> I don't think this is behaviour related to Smalltalk. I have images that stay connected to my local postgres repository continuously for long periods of time.  So I suspect this is, as reported, a firewall or other intermediate software forcing it to time out, or just having an error, although it might also be postgres having an option to kill unused connections after some time. If a socket connection dies that way, I don't think there's a way of detecting that except by trying to send some communication.
>  
Quote:

There is no particular setting in PostgreSQL for a connection timeout.
However, for TCP connections PostgreSQL enables TCP KEEPALIVE. Tom Lane
says, "If network connectivity to the client is lost the kernel will
time out and close the connection. The length of the keepalive timeout
is kernel-dependent but should be an hour or more in RFC-compliant
implementations."

Cheers!

-Boris

> At 01:46 PM 1/19/2006, Charles A. Monteiro wrote:
>  
>> Reinout:
>>
>> I have seen this behavior from just about the beginning of time, for  
>> example if you open a connection to the public repository and do nothing  
>> for a while it will disconnect itself, there is some inactive connection  
>> settings , I sort of recall having asked Peter ? whose last name escapes  
>> me at the moment.
>>
>> -Charles
>>
>>
>> On Thu, 19 Jan 2006 13:28:18 -0500, Reinout Heeck <[hidden email]> wrote:
>>
>>    
>>> That is not standard behavior, once connected you should stay connected.
>>> Saving an image with an open connection should show a reconnect dialog at
>>> image startup.
>>>
>>> I suspect you need to talk to your network administrator, my guess is  
>>> that
>>> some firewall is closing those connections after inactivity. Once closed  
>>> it
>>> seem to have  really hard time to remember that ti did that too given the
>>> timeout you complain about.
>>>
>>> If your setup cannot be changed consider creating a process in your  
>>> image that
>>> does a trivial query (database time or version or so) every five minutes
>>> using the Store db session.
>>>
>>>
>>> HTH,
>>>
>>> Reinout
>>> -------
>>>
>>>
>>> Charlie Adams wrote:
>>>      
>>>> Is there some way to maintain a connection to the database even over  
>>>> long
>>>> periods of inactivity? Or increase the timeout value?
>>>>
>>>> Since moving from Envy to Store, one of the things that I have a hard  
>>>> time
>>>> assimilating is the need to 'connect-publish-disconnect' when  
>>>> interacting
>>>> with Store/postgres. Its just one of those things that I never remember
>>>> until it is too late. If I forget, I am reminded by the incredibly long
>>>> time it takes to detect the disconnection and prompt me to reconnect. As
>>>> I've reminded my co-workers, this presents an opportunity to get up and
>>>> stretch, relax a bit and reflect on the work you've done and now want to
>>>> publish.
>>>>
>>>> But there are times when it becomes a nuisance. It would be nice if  
>>>> there
>>>> were a way to tune the connection timeout or detection thereof.
>>>>
>>>> Regards,
>>>> Charlie Adams
>>>> Adventa Control Technologies, Inc.
>>>> 3001 E. Plano Parkway, #100
>>>> Plano, TX 75074-7422
>>>> Office: 972.543.1688
>>>> FAX: 972.633.9317
>>>> http://www.adventact.com
>>>> mailto:[hidden email]
>>>>        
>>
>> --
>> Charles A. Monteiro
>>    
>
> --
> Alan Knight [|], Cincom Smalltalk Development
> [hidden email]
> [hidden email]
> http://www.cincom.com/smalltalk
>
> "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross
>  


-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Reinout Heeck
In reply to this post by Alan Knight-2
Alan Knight wrote:
> I don't think this is behaviour related to Smalltalk. I have images that
> stay connected to my local postgres repository continuously for long
> periods of time.  So I suspect this is, as reported, a firewall or other
> intermediate software forcing it to time out, or just having an error,
> although it might also be postgres having an option to kill unused
> connections after some time. If a socket connection dies that way, I don't
> think there's a way of detecting that except by trying to send some
> communication.

If this were Postgres that closed the socket the image would have known it by
way of the TCP close handshake.
The complaint about a long timeout before connection loss is detected makes me
think that it is a firewall (possibly at Cincom) not the DB.


R
-

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Bruce Badger
In reply to this post by Charles Adams
On 20/01/06, Charlie Adams <[hidden email]> wrote:
>
> Is there some way to maintain a connection to the database even over long
> periods of inactivity? Or increase the timeout value?

As others have said, this is probably something that needs to be
addressed at a network level, rather than a PostgreSQL client level.

... or you can run a PostgreSQL instance on your workstation and
connect to that instead of the remote repository, and keep the two
Store repositories in sync using replication.

This works well for me.  I've not had a connection to a local database
break in the way you describe.  Also, you'll find that Store works
much faster when you are locally connected.

HTH,
    Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

kobetic
In reply to this post by Reinout Heeck
One thing that might help controlling the length of the timeout period
would be getting the IOBuffer to do a #readWaitWithTimeout:. For
example, instead of plain #readInto: call in
IOBuffer>>readBufferStartingAt: do something like:

(input readWaitWithTimeout: timeout)
        ifTrue: [ Timeout raiseSignal. 0 ]
        ifFalse: [ input readInto: buffer startingAt: pos for: amt ]

Where 'timeout' would be either a new inst var on the buffer (settable
through the stream) or a global. That should work at least for socket
streams. File streams are handled by a different class so those
shouldn't mind. Any other streams I'm forgetting ?

Other than that it's OS's discretion as to how long it wants you to keep
waiting. Of course tuning the parameter isn't exactly trivial either.
I'm not even sure what would be a good default value.

Reinout Heeck wrote:
> If this were Postgres that closed the socket the image would have known it by
> way of the TCP close handshake.
> The complaint about a long timeout before connection loss is detected makes me
> think that it is a firewall (possibly at Cincom) not the DB.

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Charles Adams
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Boris,

What do you mean by "PostgreSQL enables TCP KEEPALIVE?" Is this a
configurable item in compiling or linking PostgreSQL? If so, then making the
length of the timeout infinitely long would mean that the application was no
longer RFC-compliant, whatever that means.

Charlie
----- Original Message -----
From: "Boris Popov" <[hidden email]>
To: "Alan Knight" <[hidden email]>
Cc: "Charles A. Monteiro" <[hidden email]>; "Reinout Heeck"
<[hidden email]>; <[hidden email]>
Sent: Thursday, January 19, 2006 12:54 PM
Subject: Re: Store/postgres inactivity disconnection


> Alan Knight wrote:
>> I don't think this is behaviour related to Smalltalk. I have images that
>> stay connected to my local postgres repository continuously for long
>> periods of time.  So I suspect this is, as reported, a firewall or other
>> intermediate software forcing it to time out, or just having an error,
>> although it might also be postgres having an option to kill unused
>> connections after some time. If a socket connection dies that way, I
>> don't think there's a way of detecting that except by trying to send some
>> communication.
>>
> Quote:
>
> There is no particular setting in PostgreSQL for a connection timeout.
> However, for TCP connections PostgreSQL enables TCP KEEPALIVE. Tom Lane
> says, "If network connectivity to the client is lost the kernel will time
> out and close the connection. The length of the keepalive timeout is
> kernel-dependent but should be an hour or more in RFC-compliant
> implementations."
>
> Cheers!
>
> -Boris
>
>> At 01:46 PM 1/19/2006, Charles A. Monteiro wrote:
>>
>>> Reinout:
>>>
>>> I have seen this behavior from just about the beginning of time, for
>>> example if you open a connection to the public repository and do nothing
>>> for a while it will disconnect itself, there is some inactive connection
>>> settings , I sort of recall having asked Peter ? whose last name escapes
>>> me at the moment.
>>>
>>> -Charles
>>>
>>>
>>> On Thu, 19 Jan 2006 13:28:18 -0500, Reinout Heeck <[hidden email]>
>>> wrote:
>>>
>>>
>>>> That is not standard behavior, once connected you should stay
>>>> connected.
>>>> Saving an image with an open connection should show a reconnect dialog
>>>> at
>>>> image startup.
>>>>
>>>> I suspect you need to talk to your network administrator, my guess is
>>>> that
>>>> some firewall is closing those connections after inactivity. Once
>>>> closed  it
>>>> seem to have  really hard time to remember that ti did that too given
>>>> the
>>>> timeout you complain about.
>>>>
>>>> If your setup cannot be changed consider creating a process in your
>>>> image that
>>>> does a trivial query (database time or version or so) every five
>>>> minutes
>>>> using the Store db session.
>>>>
>>>>
>>>> HTH,
>>>>
>>>> Reinout
>>>> -------
>>>>
>>>>
>>>> Charlie Adams wrote:
>>>>
>>>>> Is there some way to maintain a connection to the database even over
>>>>> long
>>>>> periods of inactivity? Or increase the timeout value?
>>>>>
>>>>> Since moving from Envy to Store, one of the things that I have a hard
>>>>> time
>>>>> assimilating is the need to 'connect-publish-disconnect' when
>>>>> interacting
>>>>> with Store/postgres. Its just one of those things that I never
>>>>> remember
>>>>> until it is too late. If I forget, I am reminded by the incredibly
>>>>> long
>>>>> time it takes to detect the disconnection and prompt me to reconnect.
>>>>> As
>>>>> I've reminded my co-workers, this presents an opportunity to get up
>>>>> and
>>>>> stretch, relax a bit and reflect on the work you've done and now want
>>>>> to
>>>>> publish.
>>>>>
>>>>> But there are times when it becomes a nuisance. It would be nice if
>>>>> there
>>>>> were a way to tune the connection timeout or detection thereof.
>>>>>
>>>>> Regards,
>>>>> Charlie Adams
>>>>> Adventa Control Technologies, Inc.
>>>>> 3001 E. Plano Parkway, #100
>>>>> Plano, TX 75074-7422
>>>>> Office: 972.543.1688
>>>>> FAX: 972.633.9317
>>>>> http://www.adventact.com
>>>>> mailto:[hidden email]
>>>>>
>>>
>>> --
>>> Charles A. Monteiro
>>>
>>
>> --
>> Alan Knight [|], Cincom Smalltalk Development
>> [hidden email]
>> [hidden email]
>> http://www.cincom.com/smalltalk
>>
>> "The Static Typing Philosophy: Make it fast. Make it right. Make it
>> run." - Niall Ross
>>
>
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message
> header. Unless otherwise indicated, it contains information that is
> private and confidential. If you have received it in error, please
> notify the sender and delete the entire message including any
> attachments.
>
> Thank you.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Boris Popov, DeepCove Labs (SNN)
Charlie Adams wrote:
> Boris,
>
> What do you mean by "PostgreSQL enables TCP KEEPALIVE?" Is this a
> configurable item in compiling or linking PostgreSQL? If so, then
> making the length of the timeout infinitely long would mean that the
> application was no longer RFC-compliant, whatever that means.

I would imagine this simply means that SO_KEEPALIVE option is set on
sockets and length of the keep-alive timeout is controlled by the TCP/IP
stack.

Cheers!

-Boris

>
> Charlie
> ----- Original Message ----- From: "Boris Popov" <[hidden email]>
> To: "Alan Knight" <[hidden email]>
> Cc: "Charles A. Monteiro" <[hidden email]>; "Reinout Heeck"
> <[hidden email]>; <[hidden email]>
> Sent: Thursday, January 19, 2006 12:54 PM
> Subject: Re: Store/postgres inactivity disconnection
>
>
>> Alan Knight wrote:
>>> I don't think this is behaviour related to Smalltalk. I have images
>>> that stay connected to my local postgres repository continuously for
>>> long periods of time.  So I suspect this is, as reported, a firewall
>>> or other intermediate software forcing it to time out, or just
>>> having an error, although it might also be postgres having an option
>>> to kill unused connections after some time. If a socket connection
>>> dies that way, I don't think there's a way of detecting that except
>>> by trying to send some communication.
>>>
>> Quote:
>>
>> There is no particular setting in PostgreSQL for a connection
>> timeout. However, for TCP connections PostgreSQL enables TCP
>> KEEPALIVE. Tom Lane says, "If network connectivity to the client is
>> lost the kernel will time out and close the connection. The length of
>> the keepalive timeout is kernel-dependent but should be an hour or
>> more in RFC-compliant implementations."
>>
>> Cheers!
>>
>> -Boris
>>
>>> At 01:46 PM 1/19/2006, Charles A. Monteiro wrote:
>>>
>>>> Reinout:
>>>>
>>>> I have seen this behavior from just about the beginning of time,
>>>> for example if you open a connection to the public repository and
>>>> do nothing for a while it will disconnect itself, there is some
>>>> inactive connection settings , I sort of recall having asked Peter
>>>> ? whose last name escapes me at the moment.
>>>>
>>>> -Charles
>>>>
>>>>
>>>> On Thu, 19 Jan 2006 13:28:18 -0500, Reinout Heeck <[hidden email]>
>>>> wrote:
>>>>
>>>>
>>>>> That is not standard behavior, once connected you should stay
>>>>> connected.
>>>>> Saving an image with an open connection should show a reconnect
>>>>> dialog at
>>>>> image startup.
>>>>>
>>>>> I suspect you need to talk to your network administrator, my guess
>>>>> is that
>>>>> some firewall is closing those connections after inactivity. Once
>>>>> closed  it
>>>>> seem to have  really hard time to remember that ti did that too
>>>>> given the
>>>>> timeout you complain about.
>>>>>
>>>>> If your setup cannot be changed consider creating a process in
>>>>> your image that
>>>>> does a trivial query (database time or version or so) every five
>>>>> minutes
>>>>> using the Store db session.
>>>>>
>>>>>
>>>>> HTH,
>>>>>
>>>>> Reinout
>>>>> -------
>>>>>
>>>>>
>>>>> Charlie Adams wrote:
>>>>>
>>>>>> Is there some way to maintain a connection to the database even
>>>>>> over long
>>>>>> periods of inactivity? Or increase the timeout value?
>>>>>>
>>>>>> Since moving from Envy to Store, one of the things that I have a
>>>>>> hard time
>>>>>> assimilating is the need to 'connect-publish-disconnect' when
>>>>>> interacting
>>>>>> with Store/postgres. Its just one of those things that I never
>>>>>> remember
>>>>>> until it is too late. If I forget, I am reminded by the
>>>>>> incredibly long
>>>>>> time it takes to detect the disconnection and prompt me to
>>>>>> reconnect. As
>>>>>> I've reminded my co-workers, this presents an opportunity to get
>>>>>> up and
>>>>>> stretch, relax a bit and reflect on the work you've done and now
>>>>>> want to
>>>>>> publish.
>>>>>>
>>>>>> But there are times when it becomes a nuisance. It would be nice
>>>>>> if there
>>>>>> were a way to tune the connection timeout or detection thereof.
>>>>>>
>>>>>> Regards,
>>>>>> Charlie Adams
>>>>>> Adventa Control Technologies, Inc.
>>>>>> 3001 E. Plano Parkway, #100
>>>>>> Plano, TX 75074-7422
>>>>>> Office: 972.543.1688
>>>>>> FAX: 972.633.9317
>>>>>> http://www.adventact.com
>>>>>> mailto:[hidden email]
>>>>>>
>>>>
>>>> --
>>>> Charles A. Monteiro
>>>>
>>>
>>> --
>>> Alan Knight [|], Cincom Smalltalk Development
>>> [hidden email]
>>> [hidden email]
>>> http://www.cincom.com/smalltalk
>>>
>>> "The Static Typing Philosophy: Make it fast. Make it right. Make it
>>> run." - Niall Ross
>>>
>>
>>
>> -Boris
>>
>> --
>> +1.604.689.0322
>> DeepCove Labs Ltd.
>> 4th floor 595 Howe Street
>> Vancouver, Canada V6C 2T5
>>
>> [hidden email]
>>
>> CONFIDENTIALITY NOTICE
>>
>> This email is intended only for the persons named in the message
>> header. Unless otherwise indicated, it contains information that is
>> private and confidential. If you have received it in error, please
>> notify the sender and delete the entire message including any
>> attachments.
>>
>> Thank you.
>>
>>


-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Charles Adams
Boris,

I'm sorry, but you are speaking over my head. Are these things under our
control? "our" meaning we, the users.

----- Original Message -----
From: "Boris Popov" <[hidden email]>
To: "Charlie Adams" <[hidden email]>
Cc: "Alan Knight" <[hidden email]>; "Charles A. Monteiro"
<[hidden email]>; "Reinout Heeck" <[hidden email]>; <[hidden email]>
Sent: Thursday, January 19, 2006 3:15 PM
Subject: Re: Store/postgres inactivity disconnection


> Charlie Adams wrote:
>> Boris,
>>
>> What do you mean by "PostgreSQL enables TCP KEEPALIVE?" Is this a
>> configurable item in compiling or linking PostgreSQL? If so, then making
>> the length of the timeout infinitely long would mean that the application
>> was no longer RFC-compliant, whatever that means.
>
> I would imagine this simply means that SO_KEEPALIVE option is set on
> sockets and length of the keep-alive timeout is controlled by the TCP/IP
> stack.
>
> Cheers!
>
> -Boris
>>
>> Charlie
>> ----- Original Message ----- From: "Boris Popov" <[hidden email]>
>> To: "Alan Knight" <[hidden email]>
>> Cc: "Charles A. Monteiro" <[hidden email]>; "Reinout Heeck"
>> <[hidden email]>; <[hidden email]>
>> Sent: Thursday, January 19, 2006 12:54 PM
>> Subject: Re: Store/postgres inactivity disconnection
>>
>>
>>> Alan Knight wrote:
>>>> I don't think this is behaviour related to Smalltalk. I have images
>>>> that stay connected to my local postgres repository continuously for
>>>> long periods of time.  So I suspect this is, as reported, a firewall or
>>>> other intermediate software forcing it to time out, or just having an
>>>> error, although it might also be postgres having an option to kill
>>>> unused connections after some time. If a socket connection dies that
>>>> way, I don't think there's a way of detecting that except by trying to
>>>> send some communication.
>>>>
>>> Quote:
>>>
>>> There is no particular setting in PostgreSQL for a connection timeout.
>>> However, for TCP connections PostgreSQL enables TCP KEEPALIVE. Tom Lane
>>> says, "If network connectivity to the client is lost the kernel will
>>> time out and close the connection. The length of the keepalive timeout
>>> is kernel-dependent but should be an hour or more in RFC-compliant
>>> implementations."
>>>
>>> Cheers!
>>>
>>> -Boris
>>>
>>>> At 01:46 PM 1/19/2006, Charles A. Monteiro wrote:
>>>>
>>>>> Reinout:
>>>>>
>>>>> I have seen this behavior from just about the beginning of time, for
>>>>> example if you open a connection to the public repository and do
>>>>> nothing for a while it will disconnect itself, there is some inactive
>>>>> connection settings , I sort of recall having asked Peter ? whose last
>>>>> name escapes me at the moment.
>>>>>
>>>>> -Charles
>>>>>
>>>>>
>>>>> On Thu, 19 Jan 2006 13:28:18 -0500, Reinout Heeck <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>
>>>>>> That is not standard behavior, once connected you should stay
>>>>>> connected.
>>>>>> Saving an image with an open connection should show a reconnect
>>>>>> dialog at
>>>>>> image startup.
>>>>>>
>>>>>> I suspect you need to talk to your network administrator, my guess is
>>>>>> that
>>>>>> some firewall is closing those connections after inactivity. Once
>>>>>> closed  it
>>>>>> seem to have  really hard time to remember that ti did that too given
>>>>>> the
>>>>>> timeout you complain about.
>>>>>>
>>>>>> If your setup cannot be changed consider creating a process in your
>>>>>> image that
>>>>>> does a trivial query (database time or version or so) every five
>>>>>> minutes
>>>>>> using the Store db session.
>>>>>>
>>>>>>
>>>>>> HTH,
>>>>>>
>>>>>> Reinout
>>>>>> -------
>>>>>>
>>>>>>
>>>>>> Charlie Adams wrote:
>>>>>>
>>>>>>> Is there some way to maintain a connection to the database even over
>>>>>>> long
>>>>>>> periods of inactivity? Or increase the timeout value?
>>>>>>>
>>>>>>> Since moving from Envy to Store, one of the things that I have a
>>>>>>> hard time
>>>>>>> assimilating is the need to 'connect-publish-disconnect' when
>>>>>>> interacting
>>>>>>> with Store/postgres. Its just one of those things that I never
>>>>>>> remember
>>>>>>> until it is too late. If I forget, I am reminded by the incredibly
>>>>>>> long
>>>>>>> time it takes to detect the disconnection and prompt me to
>>>>>>> reconnect. As
>>>>>>> I've reminded my co-workers, this presents an opportunity to get up
>>>>>>> and
>>>>>>> stretch, relax a bit and reflect on the work you've done and now
>>>>>>> want to
>>>>>>> publish.
>>>>>>>
>>>>>>> But there are times when it becomes a nuisance. It would be nice if
>>>>>>> there
>>>>>>> were a way to tune the connection timeout or detection thereof.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Charlie Adams
>>>>>>> Adventa Control Technologies, Inc.
>>>>>>> 3001 E. Plano Parkway, #100
>>>>>>> Plano, TX 75074-7422
>>>>>>> Office: 972.543.1688
>>>>>>> FAX: 972.633.9317
>>>>>>> http://www.adventact.com
>>>>>>> mailto:[hidden email]
>>>>>>>
>>>>>
>>>>> --
>>>>> Charles A. Monteiro
>>>>>
>>>>
>>>> --
>>>> Alan Knight [|], Cincom Smalltalk Development
>>>> [hidden email]
>>>> [hidden email]
>>>> http://www.cincom.com/smalltalk
>>>>
>>>> "The Static Typing Philosophy: Make it fast. Make it right. Make it
>>>> run." - Niall Ross
>>>>
>>>
>>>
>>> -Boris
>>>
>>> --
>>> +1.604.689.0322
>>> DeepCove Labs Ltd.
>>> 4th floor 595 Howe Street
>>> Vancouver, Canada V6C 2T5
>>>
>>> [hidden email]
>>>
>>> CONFIDENTIALITY NOTICE
>>>
>>> This email is intended only for the persons named in the message
>>> header. Unless otherwise indicated, it contains information that is
>>> private and confidential. If you have received it in error, please
>>> notify the sender and delete the entire message including any
>>> attachments.
>>>
>>> Thank you.
>>>
>>>
>
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message
> header. Unless otherwise indicated, it contains information that is
> private and confidential. If you have received it in error, please
> notify the sender and delete the entire message including any
> attachments.
>
> Thank you.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Martin McClure
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Boris Popov wrote:

> Charlie Adams wrote:
>
>> Boris,
>>
>> What do you mean by "PostgreSQL enables TCP KEEPALIVE?" Is this a
>> configurable item in compiling or linking PostgreSQL? If so, then
>> making the length of the timeout infinitely long would mean that the
>> application was no longer RFC-compliant, whatever that means.
>
>
> I would imagine this simply means that SO_KEEPALIVE option is set on
> sockets and length of the keep-alive timeout is controlled by the TCP/IP
> stack.
>

I agree.

We've seen this kind of problem where GemStone clients connect to the
server through a firewall.

A TCP socket connection normally only sends packets across the network
when it has data to send. Most firewalls keep track of which TCP socket
connection each packet it handles belongs to. The firewall must keep a
table of open sockets in order to do this. So that this table stays a
reasonable size (and probably for some security policy reasons) most
firewalls purge from their table any sockets that haven't had any
traffic in a while. This timeout is configurable, but 20-30 minutes
seems to be fairly common.

Once the firewall has removed the socket from its table, it will refuse
to pass any packets for that socket connection. The packet is simply
dropped by the firewall.

The client and server machines that are the ends of the socket
connection have no immediate way to know that the firewall has decided
that their socket is obsolete. When the TCP/IP stack at one end tries to
send data to the other, it will wait for a response. When it times out
waiting for the response, it will retry the transmission. When it
reaches its maximum number of retries, it will close the socket and
return an error to the program. This is the first clue the program has
that anything is amiss. And the machine at the other end of the socket
probably still has the socket open, because it didn't see any of this.
The timeouts and retries take typically 15-20 minutes before it gives up.

If a program opens the socket with the SO_KEEPALIVE option, the TCP/IP
stack will occasionally send some data over the network and expect a
response, just to make sure that the other end can still be reached. The
frequency with which these keepalive packets are sent is determined
globally by the TCP/IP stack in the machine. A typical time interval is
two hours. So if the PostgreSQL server's socket was opened with
SO_KEEPALIVE, and it hasn't seen any data in two hours, it'll send a
keepalive packet. The firewall, who purged that socket an hour and a
half ago, drops the packet. After another 20 minutes or so, the server
machine's TCP/IP stack gives up retrying, and notifies PostgreSQL that
the socket is closed, and PostgreSQL logs the user out.

If the VW client socket is opened with SO_KEEPALIVE, it would follow the
same sequence to eventually figure out that the socket is no longer
functional. If it is not opened with SO_KEEPALIVE, it will never figure
that out until it attempts to send some data and doesn't get a response.

Other than configuring the firewall to have an idle socket time of
longer than two hours (or whatever the keepalive time is), there isn't
much that can be done about this, other than send useless data over the
socket, which complicates the programs and wastes network bandwidth.

-Martin

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Boris Popov, DeepCove Labs (SNN)
In reply to this post by Charles Adams
Charlie Adams wrote:
> Boris,
>
> I'm sorry, but you are speaking over my head. Are these things under
> our control? "our" meaning we, the users.

Not really, keep-alive is a feature of TCP implementations that server
applications (in this case PostgreSQL) use to detect dropped client
connections in order to determine when allocated resources can be
released etc.

 From http://www.faqs.org/rfcs/rfc1122.html

                 A "keep-alive" mechanism periodically probes the other
                 end of a connection when the connection is otherwise
                 idle, even when there is no data to be sent.  The TCP
                 specification does not include a keep-alive mechanism
                 because it could:  (1) cause perfectly good connections
                 to break during transient Internet failures; (2)
                 consume unnecessary bandwidth ("if no one is using the
                 connection, who cares if it is still good?"); and (3)
                 cost money for an Internet path that charges for
                 packets.

                 Some TCP implementations, however, have included a
                 keep-alive mechanism.  To confirm that an idle
                 connection is still active, these implementations send
                 a probe segment designed to elicit a response from the
                 peer TCP.  Such a segment generally contains SEG.SEQ =
                 SND.NXT-1 and may or may not contain one garbage octet
                 of data.  Note that on a quiet connection SND.NXT =
                 RCV.NXT, so that this SEG.SEQ will be outside the
                 window.  Therefore, the probe causes the receiver to
                 return an acknowledgment segment, confirming that the
                 connection is still live.  If the peer has dropped the
                 connection due to a network partition or a crash, it
                 will respond with a RST instead of an acknowledgment
                 segment.

                 Unfortunately, some misbehaved TCP implementations fail
                 to respond to a segment with SEG.SEQ = SND.NXT-1 unless
                 the segment contains data.  Alternatively, an
                 implementation could determine whether a peer responded
                 correctly to keep-alive packets with no garbage data
                 octet.

                 A TCP keep-alive mechanism should only be invoked in
                 server applications that might otherwise hang
                 indefinitely and consume resources unnecessarily if a
                 client crashes or aborts a connection during a network
                 failure.

Cheers!

-Boris

>
> ----- Original Message ----- From: "Boris Popov" <[hidden email]>
> To: "Charlie Adams" <[hidden email]>
> Cc: "Alan Knight" <[hidden email]>; "Charles A. Monteiro"
> <[hidden email]>; "Reinout Heeck" <[hidden email]>;
> <[hidden email]>
> Sent: Thursday, January 19, 2006 3:15 PM
> Subject: Re: Store/postgres inactivity disconnection
>
>
>> Charlie Adams wrote:
>>> Boris,
>>>
>>> What do you mean by "PostgreSQL enables TCP KEEPALIVE?" Is this a
>>> configurable item in compiling or linking PostgreSQL? If so, then
>>> making the length of the timeout infinitely long would mean that the
>>> application was no longer RFC-compliant, whatever that means.
>>
>> I would imagine this simply means that SO_KEEPALIVE option is set on
>> sockets and length of the keep-alive timeout is controlled by the
>> TCP/IP stack.
>>
>> Cheers!
>>
>> -Boris
>>>
>>> Charlie
>>> ----- Original Message ----- From: "Boris Popov"
>>> <[hidden email]>
>>> To: "Alan Knight" <[hidden email]>
>>> Cc: "Charles A. Monteiro" <[hidden email]>; "Reinout Heeck"
>>> <[hidden email]>; <[hidden email]>
>>> Sent: Thursday, January 19, 2006 12:54 PM
>>> Subject: Re: Store/postgres inactivity disconnection
>>>
>>>
>>>> Alan Knight wrote:
>>>>> I don't think this is behaviour related to Smalltalk. I have
>>>>> images that stay connected to my local postgres repository
>>>>> continuously for long periods of time.  So I suspect this is, as
>>>>> reported, a firewall or other intermediate software forcing it to
>>>>> time out, or just having an error, although it might also be
>>>>> postgres having an option to kill unused connections after some
>>>>> time. If a socket connection dies that way, I don't think there's
>>>>> a way of detecting that except by trying to send some communication.
>>>>>
>>>> Quote:
>>>>
>>>> There is no particular setting in PostgreSQL for a connection
>>>> timeout. However, for TCP connections PostgreSQL enables TCP
>>>> KEEPALIVE. Tom Lane says, "If network connectivity to the client is
>>>> lost the kernel will time out and close the connection. The length
>>>> of the keepalive timeout is kernel-dependent but should be an hour
>>>> or more in RFC-compliant implementations."
>>>>
>>>> Cheers!
>>>>
>>>> -Boris
>>>>
>>>>> At 01:46 PM 1/19/2006, Charles A. Monteiro wrote:
>>>>>
>>>>>> Reinout:
>>>>>>
>>>>>> I have seen this behavior from just about the beginning of time,
>>>>>> for example if you open a connection to the public repository and
>>>>>> do nothing for a while it will disconnect itself, there is some
>>>>>> inactive connection settings , I sort of recall having asked
>>>>>> Peter ? whose last name escapes me at the moment.
>>>>>>
>>>>>> -Charles
>>>>>>
>>>>>>
>>>>>> On Thu, 19 Jan 2006 13:28:18 -0500, Reinout Heeck
>>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>>
>>>>>>> That is not standard behavior, once connected you should stay
>>>>>>> connected.
>>>>>>> Saving an image with an open connection should show a reconnect
>>>>>>> dialog at
>>>>>>> image startup.
>>>>>>>
>>>>>>> I suspect you need to talk to your network administrator, my
>>>>>>> guess is that
>>>>>>> some firewall is closing those connections after inactivity.
>>>>>>> Once closed  it
>>>>>>> seem to have  really hard time to remember that ti did that too
>>>>>>> given the
>>>>>>> timeout you complain about.
>>>>>>>
>>>>>>> If your setup cannot be changed consider creating a process in
>>>>>>> your image that
>>>>>>> does a trivial query (database time or version or so) every five
>>>>>>> minutes
>>>>>>> using the Store db session.
>>>>>>>
>>>>>>>
>>>>>>> HTH,
>>>>>>>
>>>>>>> Reinout
>>>>>>> -------
>>>>>>>
>>>>>>>
>>>>>>> Charlie Adams wrote:
>>>>>>>
>>>>>>>> Is there some way to maintain a connection to the database even
>>>>>>>> over long
>>>>>>>> periods of inactivity? Or increase the timeout value?
>>>>>>>>
>>>>>>>> Since moving from Envy to Store, one of the things that I have
>>>>>>>> a hard time
>>>>>>>> assimilating is the need to 'connect-publish-disconnect' when
>>>>>>>> interacting
>>>>>>>> with Store/postgres. Its just one of those things that I never
>>>>>>>> remember
>>>>>>>> until it is too late. If I forget, I am reminded by the
>>>>>>>> incredibly long
>>>>>>>> time it takes to detect the disconnection and prompt me to
>>>>>>>> reconnect. As
>>>>>>>> I've reminded my co-workers, this presents an opportunity to
>>>>>>>> get up and
>>>>>>>> stretch, relax a bit and reflect on the work you've done and
>>>>>>>> now want to
>>>>>>>> publish.
>>>>>>>>
>>>>>>>> But there are times when it becomes a nuisance. It would be
>>>>>>>> nice if there
>>>>>>>> were a way to tune the connection timeout or detection thereof.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Charlie Adams
>>>>>>>> Adventa Control Technologies, Inc.
>>>>>>>> 3001 E. Plano Parkway, #100
>>>>>>>> Plano, TX 75074-7422
>>>>>>>> Office: 972.543.1688
>>>>>>>> FAX: 972.633.9317
>>>>>>>> http://www.adventact.com
>>>>>>>> mailto:[hidden email]
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Charles A. Monteiro
>>>>>>
>>>>>
>>>>> --
>>>>> Alan Knight [|], Cincom Smalltalk Development
>>>>> [hidden email]
>>>>> [hidden email]
>>>>> http://www.cincom.com/smalltalk
>>>>>
>>>>> "The Static Typing Philosophy: Make it fast. Make it right. Make
>>>>> it run." - Niall Ross
>>>>>
>>>>
>>>>
>>>> -Boris
>>>>
>>>> --
>>>> +1.604.689.0322
>>>> DeepCove Labs Ltd.
>>>> 4th floor 595 Howe Street
>>>> Vancouver, Canada V6C 2T5
>>>>
>>>> [hidden email]
>>>>
>>>> CONFIDENTIALITY NOTICE
>>>>
>>>> This email is intended only for the persons named in the message
>>>> header. Unless otherwise indicated, it contains information that is
>>>> private and confidential. If you have received it in error, please
>>>> notify the sender and delete the entire message including any
>>>> attachments.
>>>>
>>>> Thank you.
>>>>
>>>>
>>
>>
>> -Boris
>>
>> --
>> +1.604.689.0322
>> DeepCove Labs Ltd.
>> 4th floor 595 Howe Street
>> Vancouver, Canada V6C 2T5
>>
>> [hidden email]
>>
>> CONFIDENTIALITY NOTICE
>>
>> This email is intended only for the persons named in the message
>> header. Unless otherwise indicated, it contains information that is
>> private and confidential. If you have received it in error, please
>> notify the sender and delete the entire message including any
>> attachments.
>>
>> Thank you.
>>
>>


-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Charles Adams
In reply to this post by Martin McClure
This all sounds too complex to try to do something about. I seriously doubt
there are very many sysadmins out there that will look kindly on my request
to tweak the firewall socket settings. Nor is it acceptable to create a
process inside VW to periodically ping the database. Therefore, it seems
there is nothing to be done, except assimilate.

Thanks to all for the info. I think this investigation is over. :)

Regards,
Charlie Adams

----- Original Message -----
From: "Martin McClure" <[hidden email]>
To: <[hidden email]>
Cc: "Charlie Adams" <[hidden email]>
Sent: Thursday, January 19, 2006 3:47 PM
Subject: Re: Store/postgres inactivity disconnection


> Boris Popov wrote:
>> Charlie Adams wrote:
>>
>>> Boris,
>>>
>>> What do you mean by "PostgreSQL enables TCP KEEPALIVE?" Is this a
>>> configurable item in compiling or linking PostgreSQL? If so, then making
>>> the length of the timeout infinitely long would mean that the
>>> application was no longer RFC-compliant, whatever that means.
>>
>>
>> I would imagine this simply means that SO_KEEPALIVE option is set on
>> sockets and length of the keep-alive timeout is controlled by the TCP/IP
>> stack.
>>
>
> I agree.
>
> We've seen this kind of problem where GemStone clients connect to the
> server through a firewall.
>
> A TCP socket connection normally only sends packets across the network
> when it has data to send. Most firewalls keep track of which TCP socket
> connection each packet it handles belongs to. The firewall must keep a
> table of open sockets in order to do this. So that this table stays a
> reasonable size (and probably for some security policy reasons) most
> firewalls purge from their table any sockets that haven't had any traffic
> in a while. This timeout is configurable, but 20-30 minutes seems to be
> fairly common.
>
> Once the firewall has removed the socket from its table, it will refuse to
> pass any packets for that socket connection. The packet is simply dropped
> by the firewall.
>
> The client and server machines that are the ends of the socket connection
> have no immediate way to know that the firewall has decided that their
> socket is obsolete. When the TCP/IP stack at one end tries to send data to
> the other, it will wait for a response. When it times out waiting for the
> response, it will retry the transmission. When it reaches its maximum
> number of retries, it will close the socket and return an error to the
> program. This is the first clue the program has that anything is amiss.
> And the machine at the other end of the socket probably still has the
> socket open, because it didn't see any of this. The timeouts and retries
> take typically 15-20 minutes before it gives up.
>
> If a program opens the socket with the SO_KEEPALIVE option, the TCP/IP
> stack will occasionally send some data over the network and expect a
> response, just to make sure that the other end can still be reached. The
> frequency with which these keepalive packets are sent is determined
> globally by the TCP/IP stack in the machine. A typical time interval is
> two hours. So if the PostgreSQL server's socket was opened with
> SO_KEEPALIVE, and it hasn't seen any data in two hours, it'll send a
> keepalive packet. The firewall, who purged that socket an hour and a half
> ago, drops the packet. After another 20 minutes or so, the server
> machine's TCP/IP stack gives up retrying, and notifies PostgreSQL that the
> socket is closed, and PostgreSQL logs the user out.
>
> If the VW client socket is opened with SO_KEEPALIVE, it would follow the
> same sequence to eventually figure out that the socket is no longer
> functional. If it is not opened with SO_KEEPALIVE, it will never figure
> that out until it attempts to send some data and doesn't get a response.
>
> Other than configuring the firewall to have an idle socket time of longer
> than two hours (or whatever the keepalive time is), there isn't much that
> can be done about this, other than send useless data over the socket,
> which complicates the programs and wastes network bandwidth.
>
> -Martin
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Bruce Badger
On 20/01/06, Charlie Adams <[hidden email]> wrote:
>... Therefore, it seems there is nothing to be done, except assimilate.

... or use a PosgtgreSQL instance on your workstation/laptop.  It's
easy to do this and it would solve the problem of a lost connection
interrupting your work.

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Charles A. Monteiro-2
sorry, I realize that this thread is meant to be over and I guess nobody  
here knows the answer but don't we have an issue in the use of Postgres in  
commercial applicationx with regards to remote connections , this happens  
to me when connecting to my repository at home from work, I have not done  
anything special on my router but open the Postgres port, which I am  
pretty sure is the case with Charlie, so special tweaking?

Is the socket based driver the only way to hook up to Postgres or is it  
jus the only way VW has to hook up to Postgres.

Isn't this an issue? Don't we need an AR? I guess apps can always do  
re-connects.

-Charles
On Thu, 19 Jan 2006 19:28:16 -0500, Bruce Badger <[hidden email]>  
wrote:

> On 20/01/06, Charlie Adams <[hidden email]> wrote:
>> ... Therefore, it seems there is nothing to be done, except assimilate.
>
> ... or use a PosgtgreSQL instance on your workstation/laptop.  It's
> easy to do this and it would solve the problem of a lost connection
> interrupting your work.
>
> --
> Make the most of your skills - with OpenSkills
> http://www.openskills.org/



--
Charles A. Monteiro

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Charles Adams
Could VW do a sort of "connection-on-demand"? That is, open the connection,
execute the db transaction and then close the connection. So, instead of
selecting a connection profile and opening the connection, we would merely
be selecting a profile to be used whenever a connection was required.

I know this puts domain (firewall) knowledge into the client (VW) and
represents an inappropriate coupling. But it would work. :) It takes
practically no time at all to connect and disconnect.

----- Original Message -----
From: "Charles A. Monteiro" <[hidden email]>
To: "Bruce Badger" <[hidden email]>; "Vwnc" <[hidden email]>
Sent: Friday, January 20, 2006 8:01 AM
Subject: Re: Store/postgres inactivity disconnection


> sorry, I realize that this thread is meant to be over and I guess nobody
> here knows the answer but don't we have an issue in the use of Postgres in
> commercial applicationx with regards to remote connections , this happens
> to me when connecting to my repository at home from work, I have not done
> anything special on my router but open the Postgres port, which I am
> pretty sure is the case with Charlie, so special tweaking?
>
> Is the socket based driver the only way to hook up to Postgres or is it
> jus the only way VW has to hook up to Postgres.
>
> Isn't this an issue? Don't we need an AR? I guess apps can always do
> re-connects.
>
> -Charles
> On Thu, 19 Jan 2006 19:28:16 -0500, Bruce Badger <[hidden email]>
> wrote:
>
>> On 20/01/06, Charlie Adams <[hidden email]> wrote:
>>> ... Therefore, it seems there is nothing to be done, except assimilate.
>>
>> ... or use a PosgtgreSQL instance on your workstation/laptop.  It's
>> easy to do this and it would solve the problem of a lost connection
>> interrupting your work.
>>
>> --
>> Make the most of your skills - with OpenSkills
>> http://www.openskills.org/
>
>
>
> --
> Charles A. Monteiro
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Charles Adams
In reply to this post by Bruce Badger
Yes, you are right. It is a complete solution.

----- Original Message -----
From: "Bruce Badger" <[hidden email]>
To: "Vwnc" <[hidden email]>
Sent: Thursday, January 19, 2006 6:28 PM
Subject: Re: Store/postgres inactivity disconnection


> On 20/01/06, Charlie Adams <[hidden email]> wrote:
>>... Therefore, it seems there is nothing to be done, except assimilate.
>
> ... or use a PosgtgreSQL instance on your workstation/laptop.  It's
> easy to do this and it would solve the problem of a lost connection
> interrupting your work.
>
> --
> Make the most of your skills - with OpenSkills
> http://www.openskills.org/
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Store/postgres inactivity disconnection

Charles A. Monteiro-2
In reply to this post by Charles Adams
i.e. basically not pop the dialog on you and just do it, i.e. connect you  
using your current connection profile,

well that would be here, I guess perhaps on some preference settings you  
can go ahead and do: "DbRegistry reconnect" below without asking the user,  
etc ...

PostgreSQLServerBroker>>>
safelyExecuteBlock: aBlock
        "^self
        It seems that 'safely' in this context means: show the database busy  
cursor and look out for 'brokerSignals' and other exceptions.  Note that  
the halt is there because in some cases exceptions have been silently  
squashed, leaving no trace - I'd prefer to know what's happening.  This  
position should be reviewed at each release of StORE."

        self uglyMethod.
        DbRegistry isOnline
                ifFalse: [^self currentlyNotConnectedSignal raiseSignal].
        ^
        [[Cursor database showWhile: [aBlock value]] on: self brokerSignals
                do:
                        [:exception |
                        Transcript
                                show: (self messageFor: exception);
                                cr.
                        DbRegistry goOffLine.
                        (Dialog confirm: 'Currently disconnected. Do you want to reconnect?')
                                ifTrue: [DbRegistry reconnect ifTrue: [exception retry]].
                        exception resignalAs: self currentlyNotConnectedSignal raiseSignal]]
                        on: UnhandledException
                        do:
                                [:ex |
                                self halt: 'UnhandledException during SQL processing.'.
                                self processPublishException: ex note: ''.
                                self currentlyNotConnectedSignal raiseSignal.
                                ^nil]


On Fri, 20 Jan 2006 10:42:41 -0500, Charlie Adams <[hidden email]>  
wrote:

> Could VW do a sort of "connection-on-demand"? That is, open the  
> connection, execute the db transaction and then close the connection.  
> So, instead of selecting a connection profile and opening the  
> connection, we would merely be selecting a profile to be used whenever a  
> connection was required.
>
> I know this puts domain (firewall) knowledge into the client (VW) and  
> represents an inappropriate coupling. But it would work. :) It takes  
> practically no time at all to connect and disconnect.
>
> ----- Original Message ----- From: "Charles A. Monteiro"  
> <[hidden email]>
> To: "Bruce Badger" <[hidden email]>; "Vwnc" <[hidden email]>
> Sent: Friday, January 20, 2006 8:01 AM
> Subject: Re: Store/postgres inactivity disconnection
>
>
>> sorry, I realize that this thread is meant to be over and I guess  
>> nobody here knows the answer but don't we have an issue in the use of  
>> Postgres in commercial applicationx with regards to remote connections  
>> , this happens to me when connecting to my repository at home from  
>> work, I have not done anything special on my router but open the  
>> Postgres port, which I am pretty sure is the case with Charlie, so  
>> special tweaking?
>>
>> Is the socket based driver the only way to hook up to Postgres or is it  
>> jus the only way VW has to hook up to Postgres.
>>
>> Isn't this an issue? Don't we need an AR? I guess apps can always do  
>> re-connects.
>>
>> -Charles
>> On Thu, 19 Jan 2006 19:28:16 -0500, Bruce Badger <[hidden email]>  
>> wrote:
>>
>>> On 20/01/06, Charlie Adams <[hidden email]> wrote:
>>>> ... Therefore, it seems there is nothing to be done, except  
>>>> assimilate.
>>>
>>> ... or use a PosgtgreSQL instance on your workstation/laptop.  It's
>>> easy to do this and it would solve the problem of a lost connection
>>> interrupting your work.
>>>
>>> --
>>> Make the most of your skills - with OpenSkills
>>> http://www.openskills.org/
>>
>>
>>
>> -- Charles A. Monteiro
>>
>>
>>



--
Charles A. Monteiro

12