> On Feb 6, 2016, at 1:53 PM, Jan Sindberg <[email protected]> wrote: > > When an application such as Fortress Commander is left inactive for hours - > all connections in the connection pool is closed (timed out ?). But for > each connection there is a 30 sec. timeout before the conclusion that the > connection is dead. With 10 connections that is a five minutes wait for the > first "unknowing victim" and an application-log with ten equal logs > including stack trace.
A connection sometimes times out inside the client connection pool, on the server-side, or within the intermediaries (firewalls). First thing we’ll need is the stack trace and your fortress.properties, with necessary redactions of course, in order to (try and) pinpoint the root cause. > > On Feb 6, 2016, at 1:53 PM, Jan Sindberg <[email protected]> wrote: > > How are you dealing with this in your systems? > Can I configure this differently from Fortress or in ApacheDS? > Could we make Fortress be a little faster realising that the connection > pool needs to be "refreshed"? > I guess the issue could be simulated by restarting ApacheDS (I haven't > tested this yet) - that should break whatever open connections there we. There are settings in the client-side pooling mechanism that affect this behavior. There are code changes that can be made. There are settings on the server. But first we must understand why it’s happening in your tests. Just to be clear - what you're describing here is very bad behavior for an application to have, and deserves serious attention from us. To put it simply, it’s a show-stopper. Just now, I ran a couple of tests inside my local env. Using openldap as the server, and a max idle timeout of 30 seconds. After 30 seconds of inactivity, slapd will forcefully terminate any connections being held open by a client. I also had fortress web deployed to tomcat. First I restarted slapd daemon with open browser session logged into the app. Next I left the web session open for around 10 minutes. Neither test case resulted in a failure. For my tests, the ldap connection pool managed to recover. I need to re-run the same tests using ApacheDS server, and will will once I learn how to set its max idle timeout. But, just because I can’t recreate your issue inside my local env doesn’t tell us much. The good news, once we’ve got repeatable steps to recreate, this problem ought to get solved quickly. Thanks for reporting it, Shawn
