D
dbeavon
Guest
>> It is the same protocol we created for Classic AppServer that assumes a persistent socket connection between client and server. We have a feature in our backlog to create a truly stateless APSV transport I agree that ideally a "session-free" connection to PASOE should not rely on an extremely long-lasting HTTP session. We encountered some of the related challenges very early in our migration to PASOE, and were forced to extend our default tomcat session timeouts from 30 mins to 3000 mins. But if it is such a large undertaking to fix the "APSV" protocol, then a workaround could be used for now (in a way that doesn't involve changing the protocol itself). Although it is a bit counter-intuitive, the openclient applications seem to have an internal session pool of "session-free" HTTP sessions. The pool is fairly fragile at the moment but, if it were able to repair itself when HTTP sessions timed out, then it would alleviate the need to support such extremely long-lasting HTTP sessions. That may allow us to go back to using 30 minute inactivity timeouts in tomcat again! It would not be a truly stateless transport but, for the purposes of most "session-free" application clients, it would probably work just as well. In regards to the topic of the original problem with the tomcat session-manager, I opened a tech support case. It describes how PASOE suffers with enduring problems after a very temporary period of database connectivity failures. The case is 00548819.
Continue reading...
Continue reading...