Re: Again: Connection break during waiting for resultset - how to deal with?
On 24 Jun, 11:24, "Dirk Gunsthövel" <d...@guncon.de> wrote: > Hello, > > after most of the ng and mail answers indicated that > nobody seems to have this problem I prepared > a little screen demo. > > You can find this at > > http://www.guncon.de/ifx_dead_con/ > > Any comments? > > Regards, > Dirk > > -- > -- Dirk Gunsthoevel IT Systemanalyse phone: +49 (0)251 28446-0 > -- Hammer Str. 13 fax: +49 (0)251 28446-55 > -- D-48153 Muenster http://www.GunCon.de/ > -- "It ain't over 'til it's over." If this i using a TCP connection then you will need to wait for tcp to timeout the connection via the "keepalive" mechanism that is normally around 10 minutes. Read up to TCP keepalive and the good reasons why the timeout is so high.
Hi, thank you for your reply. I would happily see a around 10 minutes timeout. The problem is that this stale client state remains the same forever. ... or at least 8 hours (longest patience interval someone had) which is anyways too close to "forever". My question is how to deal with this situation. It comes up with some batch processes I run once in a while - leading to a defunc data exchange and making it necessary to start the process again. At a customer site when running about 10 processes in parallel 24/7 this happens about once a month - when they have a network problem or alike. Its rare but its nasty. Solutions include setting a query timeout or having a thread supervising the whole thing. I wonder if there is a standard way to deal with this. Thanks again Dirk <david@smooth1.co.uk> schrieb im Newsbeitrag news:d0ece753-4ca1-467d-b7d7-5719e1eccdee@y21g2000hsf.googlegroups.com... If this i using a TCP connection then you will need to wait for tcp to timeout the connection via the "keepalive" mechanism that is normally around 10 minutes. Read up to TCP keepalive and the good reasons why the timeout is so high.
On 25 Jun, 12:07, "Dirk Gunsthövel" <d...@guncon.de> wrote: > Hi, > > thank you for your reply. I would happily see a around 10 > minutes timeout. > > The problem is that this stale client state remains the same forever. > > ... or at least 8 hours (longest patience interval someone had) which > is anyways too close to "forever". > > My question is how to deal with this situation. It comes up with some > batch processes I run once in a while - leading to a defunc data > exchange and making it necessary to start the process again. > > At a customer site when running about 10 processes in parallel > 24/7 this happens about once a month - when they have a network > problem or alike. Its rare but its nasty. > > Solutions include setting a query timeout or having a thread supervising > the whole thing. > > I wonder if there is a standard way to deal with this. > > Thanks again > Dirk > > <da...@smooth1.co.uk> schrieb im Newsbeitragnews:d0ece753-4ca1-467d-b7d7-5719e1eccdee@y21g2000hsf.googlegroups.com... > > If this i using a TCP connection then you will need to wait for tcp to > timeout the connection via the "keepalive" mechanism > that is normally around 10 minutes. Read up to TCP keepalive and the > good reasons why the timeout is so high. Enable tcp keepalive.