D
dbeavon
Guest
Hi Michael, thanks for the response. Yes we use APSV transport, and yes, there are clients that disconnect ungracefully for a variety of reasons. We can minimize some of that but only to an extent. In the end, the health of the PASOE server shouldn't be affected when client connections are dropped unexpectedly. We use HTTP sessions for APSV. This is the default these days, as I recall. And it seemed to be the way to support our load-balancing requirements (with cookie persistence). FYI ... One of the factors that makes the problem worse than it should be is that the web.xml's session timeout needs to be very high (at least 24 hours). Otherwise the "state-free/session-free" openclients for .Net would crash because the long-lived client-side connection would become invalidated/corrupted. I can point you to that KB if you want to see it. So I'd like a way to programmatically adjust the default session timeout (from 24 hours down to a fraction of that), depending on the specific type of work that is being done. I see that the tomcat "manager" app also has a REST interface that can be used for expiring sessions... so I suppose we could program the "administrative" expiration of certain types of sessions after-the-fact. But it would much prefer it if the TC session timeout could be specified up-front from ABL code. (Another workaround I discovered is to create multiple webapps, where each has its own web.xml with its own default session timeout. But this seems like a substantial overhead just to change the HTTP session timeout.)
Continue reading...
Continue reading...