Store/postgres inactivity disconnection
Locked
12
12
Store/postgres inactivity disconnection
 
|
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] |
Re: Store/postgres inactivity disconnection
|
|
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] |
Re: Store/postgres inactivity disconnection
|
|
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 |
Re: Store/postgres inactivity disconnection
|
|
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 |
Re: Store/postgres inactivity disconnection
|
|
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 |
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. |
Re: Store/postgres inactivity disconnection
|
|
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 - |
Re: Store/postgres inactivity disconnection
|
|
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/ |
|
|
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. |
Re: Store/postgres inactivity disconnection
|
|
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. > > |
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. |
Re: Store/postgres inactivity disconnection
|
|
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. > > |
Re: Store/postgres inactivity disconnection
|
|
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 |
Re: Store/postgres inactivity disconnection
|
|
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. |
Re: Store/postgres inactivity disconnection
|
|
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 > > |
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/ |
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 |
Re: Store/postgres inactivity disconnection
|
|
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 > > > |
Re: Store/postgres inactivity disconnection
|
|
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/ > > > |
Re: Store/postgres inactivity disconnection
|
|
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 |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |