Eric, The problem is a firewall that sits between the servers and the database. It is an idle session timeout of 30 minutes, so it is silently killing the connection. I have reached out to our Network Engineering department but they are saying they can not change that idle session timeout, nor create a special rule to allow this connection to bypass that rule.
Currently, I setup a polling device that calls the applications URL every 20 minutes. This causes the connection between the server and DB to refresh it's idle timeout. This is obviously a very hacky way to handle it, so I am trying to look into AR and Oracle_Enhanced to see if they have some sort of keepalive option for the database. I thought it would work with the reaping_frequency, but apparently that does not work out as I had expected when you are not running in pools or a thread. So I'm still on the lookout for something to handle that. On Wed, Aug 6, 2014 at 5:45 AM, Eric Wong <[email protected]> wrote: > > > Any update? It looks like your DB driver is not using/respecting any > timeout at all[1]. It is bad to not have a timeout there. There should > be a way to set a timeout so you can at least tell the user the DB > connection dropped or maybe get your app to disconnect+retry once. > > A better looking strace would be something like: > > write(fd, ...); => success > (poll|select|ppoll) syscall ... > read(fd, ...); /* only if (poll|select|ppoll) was successful[2] */ > > This goes for configuring all connections/services for any app. > > [1] or if it's relying on SO_RCVTIMEO socket option(rare), that's set > way too high. Any timeout set for any external connection should > be lower than the unicorn (last-resort) timeout feature. > > [2] any read() syscall after (poll|select|ppoll) should be non-blocking, > because (poll|select|ppoll) may spuriously wakeup.
