For e.g. if you set the "monitoring-attribute-name" to be "user-name" then it will use the string value of the session attribute named "user-name" as the value for Monitoring ID instead of the randomly generated value. When getMonitoringID(sessionid) method is called on the ServletSession, it will return session.getAttribute("user-name").toString().
weblogic.xml
-------------
...
600
user-name
true
...
So if you have an attribute within the HTTP Session which can identify the user/session uniquely then you can use that as the monitoring id. This is the recommended approach to track/monitor sessions instead of the session id which is an internal attribute. If you don't set the monitoring-attribute-name, WLS will randomly generate a monitoring id for each session. When developers set the monitoring-attribute-name, this will help administrator to associate sessions to the actual users.
Sample WLST script to get all the monitoring ids (for the respective session) as an array:
...
AppName = 'MedRecEar'
TargetServerName = 'MedRecSvr1'
WebCompName = 'MedRecWar'
serverRuntime()
cd('ApplicationRuntimes/' + AppName + '/ComponentRuntimes/' + TargetServerName + '_/' + WebCompName) MIDs = mon_ids = cmo.getServletSessionsMonitoringIds()
...
In the above example, the variable mon_ids will contain an array of monitoring ids as strings. Using these monitoring ids information about the individual session can be obtained from other operations like:
- getSessionLastAccessedTime
- getSessionMaxInactiveInterval
One can even invalidate the session using the following opertion:
- invalidateServletSession
This will give an option for administrators to cleanup or delete stale sessions if there are any. These are the only information that are exposed for sessions unless you want to use the deprecated ServletSessionRuntimeMBeans. This is an old MBean that has more methods/operations. Admin console doesn't expose the session id for security reason. If you need access to all the session ids for some reason then you have to use this deprecated ServletSessionRuntimeMBeans. You can get all the ServletSessionRuntimeMBeans as an array from a WebAppComponentRuntimeMBean using a deprecated getServletSessions() method. WLST script to access the above mentioned deprecated ServletSessionRuntimeMBeans:
...
AppName = 'MedRecEar'
TargetServerName = 'MedRecSvr1'
WebCompName = 'MedRecWar'
serverRuntime()
cd('ApplicationRuntimes/' + AppName + '/ComponentRuntimes/' + TargetServerName + '_/' + WebCompName + '/ServletSessions')
ls()
....
The above ls() command will list you all the sessions with session id as their name. Even though this post has lot of information on how to monitor sessions and make use of the monitoring-attribute-name, I shall write another to provide a complete example of how to use this.
Also see my other post on how to monitor HTTP sessions from the administration console and WLST.
Hi Bala,
ReplyDeleteSorry for this way I asking you, but I have a serious problem and I'm a bit desperate. My problem, that I generate a domain with the weblogic.WLST (with a jython file similar to your example at
http://weblogicserver.blogspot.com/search/label/Domain%20Creation
which worked perfectly, but after I started a server (for example the Admin), I cannot change any attribute with a command like this:
java weblogic.Admin -url t3://localhost:7001 -username weblogic -password weblogic1 SET -mbean myDomain:Location=AdminServer,Name=AdminServer,Type=ServerConfig -property ListenAddress x.x.x.x
I'vo got always the error message:
Attribute is readonly. : myDomain:Name=AdminServer,Location=AdminServer,Type=.......
But if I create a Server on the fly with
java weblogic.Admin .... CREATE -mbean myDomain:Name=ManagedServer,Type=Server
And then I try to change its listen address with the command earlier, it works.
Any idea? Thanks in anticipation.
You are trying to change the Config MBean. Try changing the Admin MBean with no suffix for eg. Type=Server.
ReplyDeleteThis is first time i read your article..It is good information.I really appreciate you did very great work.Thanks for sharing a wonderful information.
ReplyDeleteEcommerce developer