Using WLST Script To List Messages From A JMS Queue

WebLogic Server added support for Runtime Message Management for Destination hosted on WebLogic JMS Servers in WLS 9.0. It will an exciting feature if you are currently in WLS 8.1 or new to WLS. Now you can administratively view and browse all messages, and manipulate most messages in a running JMS server, by using the Administration Console or WLS public runtime APIs. Once I start getting excited about this feature to customer the very next logical question from administrators are can I script this? The answer is obviously, Yes. Java or WLST is your answer. If you are a developer and there is a requirement to provide a Java/JEE application for your administrators or business users to view or browse the messages then Java will be your option. For administrators who are non-Java, there are MBeans like JMSDestinationRuntimeMBean and JMSDurableSubscriberRuntimeMBean that you can use from WLST to script any of the message managment features. Needless to say if there are existing Java implementation for message management then you can simply import and use them within WLST as well. But WLST scripts are natural choice for administrators.

So I started out writing a simple WLST script that can list all the messages from a given JMS Queue. The script is written to list all the headers and properties along with the body. I have made enough comments in the script to explain the different steps. But the high-level steps are:

1. Connect to the server
2. Get to the JMSDestinationRuntimeMBean
3. Get the cursor to find the number of messages
4. Get the messages without body to find the cursor and the Message ID
5. Get the message with body using the Message ID
6. Print the Headers, Properties and Body (or) Pay Load of the Message

A key information to note here is if you have any Object Messages in the Queue then those classes should be added to the Java Classpath before you execute this WLST Script. I haven't implemented any exception handling logic in my script whereas handling exceptions are best practices and you might want to refer to my other entries regarding that information.

#Import necessary classes/interfaces
from weblogic.jms.extensions import JMSMessageInfo
from javax.jms import TextMessage
from javax.jms import ObjectMessage

#Define constants
url='t3://localhost:7001'
username='weblogic'
password='weblogic1'
jmsservername='test-jms-server'
jmsmodulename='test-jms-module'
jmsdestname='test-queue'

#Connect
connect(username,password,url)

#Switch to the server runtime tree
serverRuntime()

#Navigate to the JMS Destination Runtime MBean
cd('JMSRuntime/' + serverName + '.jms/JMSServers/' + jmsservername)
cd('Destinations/' + jmsmodulename + '!' +  jmsdestname)

#Get the cursor (JMSMessageCursorRuntimeMBean) to browse the messages - No selector & No time out
cursor = cmo.getMessages('',0)

#Determine the number of messages in the destination
cursorsize = cmo.getCursorSize(cursor)
print '------------------------------------------'
print 'Total Number of Messages -> ', cursorsize
print '------------------------------------------'

#Get all the messages as an array of javax.management.openmbean.CompositeData
messages = cmo.getNext(cursor, cursorsize)

#Loop through the array of messages to print
for message in messages:

#Create WebLogic JMSMessageInfo to get Message ID
jmsmsginfo = JMSMessageInfo(message)
wlmsg = jmsmsginfo.getMessage()
wlmsgid = wlmsg.getJMSMessageID()

#Get Message with body
fullcursormsg = cmo.getMessage(cursor,wlmsgid)
fulljmsmsginfo = JMSMessageInfo(fullcursormsg)
handle = fulljmsmsginfo.getHandle()
compdata = cmo.getMessage(cursor, handle)
msgwithbody = JMSMessageInfo(compdata)

#Print Key Message Headers
print 'Message ID           - ' + msgwithbody.getMessage().getJMSMessageID()
print 'Message Priority     -' , msgwithbody.getMessage().getJMSPriority()
if msgwithbody.getMessage().getJMSRedelivered() == 0:
    redeliv = 'false'
else:
    redeliv = 'true'
print 'Message Redelivered  - ' + redeliv
print 'Message TimeStamp    -' , msgwithbody.getMessage().getJMSTimestamp()
print 'Message DeliveryMode -' , msgwithbody.getMessage().getJMSDeliveryMode()

#Print Message Properties
prop_enum = msgwithbody.getMessage().getPropertyNames()
print ' '
print 'Message Properties   :'
print ' '
for prop in prop_enum:
    print prop + ' - > ' + msgwithbody.getMessage().getStringProperty(prop)

#Print Message Body
fullwlmsg = fulljmsmsginfo.getMessage()
print ' '
print 'Message Body         :'
print ' '
if isinstance(fullwlmsg, TextMessage):
    print fullwlmsg.getText()
else:
    if isinstance(fullwlmsg, ObjectMessage):
        print fullwlmsg.getObject()
    else:
        print '***Not a Text or Object Message***'
        print fullwlmsg.toString()
print ' '
print '--------------------------------------------------------------'
print ' '

#Close cursor as No Time Out specified - Best practice
cmo.closeCursor(cursor)

#Disconnect & Exit
disconnect()
exit()

Does your WLS File Store grow in size?

JMS Server in WLS only removes the messages that are expired once in every expiration scan interval (A JMS Server level config). The destination may have expired message sitting in them if the expiration scan interval property is set to a high value. For ex. 1800 will cause the JMS Server to scan for expired messages once in 30 mins. Still applications cannot receive the expired messages - they will be sitting in the destination. But it doesn’t automatically do any compaction per se. So the file size of the WLS File Store may keep increasing. This might cause slow startup of the server.

You can perform manual offline compaction in the following ways:

• There is a Java command-line utility that can do this trick "weblogic.store.Admin". See Edocs for more info.
  

• A WLST command called "compactstore" can also do the same trick. See Edocs for more info.

Note that this compaction is supported only for WLS File Stores and not for JDBC Stores as they don't suffer with the same issue of compaction.

The Java command-line utility "weblogic.store.Admin can also be used to dump the contents of a store into an XML file for troubleshooting purpose.