Has anyone else tried using PASOE 11.7 with APSV session-free clients yet?
The combination of those things should cause any open client application to crash after 30 mins. Apparently this is true for both Java and .Net open clients. I was pretty surprised when I first noticed it.
I opened a support ticket with Progress and they created the following KB for the issue. https://knowledgebase.progress.com/articles/Article/pasoe-failures-after-a-period-of-inactivity . Most of my questions about this are answered; but the thing that still confuses me is why I encountered this so early in my PASOE evaluation which started a few months ago. I would not have expected that I would be the first on OE 11.7.2, nor the first to use the APSV transport. Note that in OE 11.7, the APSV transport now integrates with tomcat HTTP sessions by default.
As I learned the hard way, APSV openclients will crash after being idle for 30 mins. The reason it takes 30 mins is because that is the default timeout for tomcat's HTTP sessions. And the APSV transport will now rely on tomcat's HTTP sessions while communicating with remote clients. So after exactly 30 mins, any expired session that you may attempt to use will likely cause your app to crash. This is the case for all sessions that are found in the session-free session pool; they will all become invalidated and, the next time you attempt to call an appserver method using the openclient connection, the application will crash.
My theory is that there aren't many other customers who use OE version 11.7 in production yet, since it is less than a year old. Based on what tech support has told me, this issue should not affect customers on OE 11.6. For customers that plan on upgrading to OE 11.7 you may want to test your APSV applications and see how they behave after tomcat session expiration (which is 30 mins by default).
I experienced this in testing migration of Classic AppServer clients over the PAS. Our clients are ABL GUI clients that can log on in the morning and walk away for hours. Rather than attempting to rewrite our connection logic I quickly simply turned off HTTP sessions during testing and never looked back.
Thanks for the feedback. It is good to know that another customer tested OE 11.7 in an application that was open for longer than 30 mins. ;) Apparently what you described was the primary workaround. Have you taken this configuration to production yet? I had some concerns that it would only substitute one type of problem for another.
When you turn off HTTP sessions for APSV in 11.7, my understanding is that it substitutes another type of session internally (it will start exclusively using the classic AIA APSV sessions.) See https://knowledgebase.progress.com/articles/Article/What-are-the-types-of-OpenEdge-sessions for discussion about PASOE sessions. From what I've seen these have no visibility in the OEE interface, making them very hard to manage, despite the fact that they are hosted inside the tomcat server process. I have concerns that they will be leaked over time, and cause memory problems especially in the context of our session-free connections, which is the primary type of connection that we use.
The other problem I had with turning off HTTP sessions is that, being new to PASOE, I didn't want to use a customized and non-standard configuration. We also wanted to be able to use a Netscaler load balancer in front of PASOE for higher availability.
We are currently running some trials in production with a small set of users (we updated our logic so that we can move users between PASOE and Classic appservers without interruption), and have not yet noticed memory growth issues on the Tomcat process. I did notice some left over 'Connections' that appear to be related to PC reboots (our IT group security policies sometimes do that for us unexpectedly), or other non-standard application exits. Currently making adjustments to the 'Idle Resource Timeout' to see if that clears things up.