[Progress Communities] [Progress OpenEdge ABL] Forum Post: Does anyone understand the "sessions" entities displayed on this PASOE admin screen in OEE?

  • Thread starter Thread starter dbeavon
  • Start date Start date
Status
Not open for further replies.
D

dbeavon

Guest
Hi, We are preparing to use PASOE in production for the first time next week. It has been a bit of a learning curve coming from "classic" appserver. But after a year of playing around with PASOE in our pre-production environments, I think I'm finally comfortable moving ahead. For administration and troubleshooting we will rely heavily on both the tomcat ("manager") webapp, and the OEE console. Within the OEE console, the screen I use the most is the "agents" circled in blue below. It is extremely helpful. But a lot of the time I try to avoid the OEE "sessions" screen (circled in red) because it often seems to contain inaccurate or misleading data. There may be multiple factors (specific to our usage patterns) that cause this data to appear the way it does. Our appserver activity primarily consists of SESSION_FREE connectivity over APSV, and we have HTTP sessions enabled. Perhaps the screen isn't designed for that combination of factors. Below is a screenshot showing an entire table of misleading or incorrect data. First I should say that the "Session ID" (red arrow) is SOMETIMES meaningful and will sometimes correspond to a tomcat HTTP session that can be found in the tomcat-manager. But if I am NOT able to find the "Session ID" on the tomcat-manager screens then I basically assume that the OEE "sessions" have become confused and probably has a bunch of orphaned records in it's internal memory that it is unable to rid itself of. ... I should note some other details that cause me to doubt the the table of misinformation that is shown above. I can go to the tomcat-manager page and invalidate/expire HTTP sessions at any time. When I do this, the related "Session IDs" in the screen above will be cleared away. But the doubtful stuff is the cruft that is left over and can't be explained. Similarly, if the "Session ID" in the table above is valid (and corresponds to a legitimate session that is listed in the tomcat-manager) then the "stop" button will work properly and I can stop that sesson. But where a cruft session is concerned (one that isn't represented in tomcat-manager) the "stop" button doesn't do anything. I can click it repeatedly for that type of session and nothing will happen. Finally I should mention that if I use the tomcat-manager to invalidate/expire all HTTP sessions, and if I also kill all the MS-Agent processes for the ABL application, then the cruft sessions should be totally orphaned without anything connected to them on any side. Yet they continue to remain visible in the OEE "sessions" list. The only way to clear them out once-and-for-all is to stop the entire PASOE instance and restart. Fortunately for me, I have not found that many reasons for using this "sessions" administration screen in the OEE console. But because it is the very first menu item in the ABL application window, it seems to me that it should work a little better than it does. I'd like to continue avoiding it, but at the same time it seems so prominent that it is hard to ignore. It is hard to explain to other PASOE users that they should avoid it, and they should instead rely on the tomcat-manager session information. If anyone has a good understanding of this screen, or why there would be items in this table that have no relationship to tomcat sessions, then I would greatly appreciate some insight into what is going on here. The contents of the screen will grow until we eventually restart PASOE. Something ain't right. And while I'm asking, what is the "session pool ID" that is shown in this table? I haven't found any google hits for that at all. I'm wondering if that might indicate that we may be using PASOE in a non-standard way that might be creating unusual problems. I am open to any and all suggestions. Thanks in advance.

Continue reading...
 
Status
Not open for further replies.
Back
Top