Tomcat Manager Webapp Download
Merci Malagarie
This question has been asked at least 5 times here or at stackoverflow, but in virtually all cases either a pre tomcat7 version causes trouble or the tomcat-users.xml is syntactically incorrect. I'd appreciate it if you help me find my errors.
Thanks to ubuntu IRC support, someone pointed out I have erroneous config data. If you look at my very first tomcat-users.xml, you will see that two role tags are not matched. So I fixed that and it now all works fine.
PS Editing server.xml was not necessary at all; furthermore, I suggest to anyone using tomcat version 7 and above to avoid defining roles not described in the official documentation. Especially, I have found several forum threads and blogs on the Net reccomending adding admin as a role, which will not work since admin is a reserved keyword.
Now I just wanted to know, can I delete docs and examples from the webapps folder without harming the server? I would assume that the other three webapps do serve some important purpose. All in all, if I do remove them, it will save me about 2.5 minutes on average every time I start the server.
If I access /manager from a web browser, I get a 404 error from Tomcat: "requested resource not available." If I access /manager/images I get the same thing. If I access /manager/401.jsp I get the actual page.
In addition, the server.xml has not only the usual Realm (UserDatabaseRealm) but also one for MySQL authentication (JDBCRealm). Investigating this showed that the role of manager was not present there for the user admin; I fixed that by doing:
I tried installing tomcat6-admin using "sudo apt-get install tomcat6-admin" on ubuntu, I was told the package is already up to date. I decided to copy /usr/share/tomcat6-admin/manager to to tomcat6 webapps directory. It works now.
I like to have the Tomcat manager webapp installed on each instance, so I can play with the webapps, and see how many active sessions there are. To do this, make a file called manager.xml file in $CATALINA_BASE/conf/[Engine]/[hostname]/. Following the default Tomcat installation, this would be $CATALINA_BASE/conf/Catalina/localhost.
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.
I think it is silly to have a "sessions" link within a *particular* ABL application if the link is going to display *all* the sessions across the entire tomcat instance. A better approach for monitoring sessions is to use the tomcat "manager" webapp instead. I would ignore the misleading information in OEE/OEM and just use the corresponding details from tomcat itself. That information is a lot more reliable and authoritative.
So the "sessions" seem to be top-level session-manager entities. They do not seem to be associated with any particular ABL application. In the very least, this appears to be a bad user interface design. These sessions aren't attributed to a particular ABL application and they probably shouldn't be listed in a way that implies something different. Also, if the information is overly technical/internal (as it appears to be), then it should be hidden or summarized, and expanded only when absolutely necessary. Today it is presented very prominently in the very first link that is shown within an ABL application.
Any tips would be appreciated. Tomcat's resident memory is growing to about 1 GB and I'm a bit suspicious of these "sessions" (assuming they are part of the session manager that is loaded within tomcat itself). I've found no documentation to explain these details that are shown in the OEE console (and now available via REST too).
Is this list of session data from the session manager, or from somewhere else? You say that the agent information is null/empty. Is that common? Does that always happen between session-free calls, for example?
Also, what would you expect the behavior to be if I were to expire the related session ID's from the tomcat manager (at :8810/manager )? Should the sessions go away (the ones that are listed within the OEE console)?
My experience is that this list of session data does not get cleared away, even after all the related session ID's are expired in the tomcat manager, and all the related MS-agent processes are ended as well. Can you point me to any documentation about this list of session data, so I understand what it is telling me?
These are the list of sessions available in session manager. Agent information is null or empty, if we just have connections and no requests running. If we have something running in the ABL session then we would see something like this
I suspect you are right that the sessions will look this way in certain common scenarios (where session-free connections were made using http tomcat sessions, but no requests are currently underway.).
What bothers me is when I go and manually expire all the tomcat http sessions but this list of session manager sessions remains as-is. Ie. Given that the "sessionID" property - in the session manager list - appears to be a reference to the tomcat session id, then you would think that this list of session manager sessions would immediately become empty as a result of expiring tomcat sessions. That doesn't always seem to be the case. I can't find a pattern.
Thanks for helping me understand this better. I am worried about the day that this sessions list jumps to thousands of entries, or the tomcat memory usage grows to multiple gb. Hopefully by that time I will have a better grasp on what I'm looking at in the oee management console.
As Rohit pointed out on the other forum question, this is a question for PASOE. If you haven't already, please open a support case. This may need a bug logged with the /oemanager web application where OEM/OEE gets its data from.
Also, if you have session hanging and if you were trying to terminate the session either with terminate session API using oemanager or by tomcat manager then it has to expire. If it did not then it is a bug.
Hi Irfan, thanks for your input. I think you may have it backwards. The tomcat instance knows which webapp the session is connected to, and is able to associate the HTTP session with a related *webapp*. This information is available in the tomcat "manager" webapp. But when the OEM console tries to enumerate the sessions based on the ABL application, then the underlying tomcat instance will not directly help to produce that list, hence the misinformation that is shown in the OEM console. If you view the sessions, in the OEM console (within an ABL application) they are not limited to any single ABL application nor any single webapp. Please see that KB for more explanation.
In our configuration we have only one webapp for each ABL application. But the outer PASOE instance has multiple of these webapp/ABL-app pairs. The sessions that are listed in the OEM console are *never* specific to a single webapp, nor a single ABL application. The sessions are a combination of *all* the sessions across the entire tomcat instance. You might want to set up this configuration to see for yourself. I'd also suggest connecting from a large number of long-lived state-free client sessions, so that the problem is accentuated.
8d45195817