D
dbeavon
Guest
>> Out of interest is this something you do regularly in your environment? Not by choice. There is a problem with APSV transport as it relates to the "session-free" openclients. These types of openclients connect only once and then they re-use a dedicated HTTP connection for long periods of time (for all round-trips over the life of the client application). The problem is that this worked well in classic appserver and not so well in PASOE. In PASOE the default HTTP session timeout configuration causes the connection to be broken after a "reasonable" tomcat session timeout - a number of minutes. Then the "session-free" openclient will encounter this broken connection the next time it needs to make an appserver round-trip. Things go from bad to worse because of the way in which the openclient will raise a generic, low-level communication exception and crash the entire client application. So the fix that we were given by PSC tech support is to increase the default HTTP session timeout configuration. I think we have it set to 24 or 48 hours! This avoids the continual crashing of our .Net openclient applications.. But the tradeoff is that there is now a greater potential for resource leaks. The number of abandoned HTTP sessions may grow over the course of a day (as yours are doing) and these abandoned sessions may hold onto various types of resources (primarily tomcat and msagent memory). By using the tomcat manager to expire the HTTP sessions, it will administratively release those resources, even if 24 hours haven't yet elapsed. Another way to avoid all of this is to use the "session-managed" connections to PASOE (rather than "session free"). That model doesn't maintain long-running connections to the server. It creates new connections for every round-trip. This avoids the need for the extremely long HTTP session timeouts. But the round-trips will have quite a lot of additional overhead (10's or 100's of ms each) since new connections being opened and closed.
Continue reading...
Continue reading...