JMS Message Management
JMS Message Management
A Technical Whitepaper
[DRAFT- UNDER REVIEW]
By
Kathiravan Sengodan
WebLogic Server Messaging Team
March 2009
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 1 of 87
1 Abstract............................................................................................................................4
2 An Overview Of WebLogic Runtime Infrastructure.........................................................4
3 WebLogic Runtime Administration Tools........................................................................9
3.1 WebLogic Administration Console............................................................................9
3.2 WebLogic Scripting Tool (WLST)..........................................................................10
3.2.1 Basic Concepts around using WLST................................................................10
3.2.2 Creating a Simple JMS Configuration..............................................................14
4 JMS Runtime State Monitoring and Administration......................................................16
4.1 Pause/Resume Using Console.................................................................................18
4.2 MBean API for Pause/Resume................................................................................19
4.3 Pause/Resume Using WLST....................................................................................20
4.4 Caveats and Best Practices......................................................................................21
5 JMS Runtime Statistics Gathering..................................................................................21
5.1 JMS Runtime Statistics using Console....................................................................22
5.2 MBean APIs for Runtime Statistics.........................................................................24
5.2.1 Top level JMS Runtime Statistics.....................................................................24
5.2.2 JMS Message statistics from JMSDestinationRuntimeMBean........................25
5.3 JMS Runtime Statistics using WLST......................................................................26
5.3.1 Top Level JMS Runtime Statistics Gathering...................................................26
5.3.2 JMS Message Runtime Statistics Gathering.....................................................26
5.4 Caveats and Best Practices......................................................................................27
6 Basic Concepts around Message Management...............................................................28
6.1 JMS Message Selectors...........................................................................................28
6.2 JMS Message Meta-Data.........................................................................................29
6.3 JMS Message Cursors..............................................................................................31
7 Message Browsing..........................................................................................................31
7.1 Message Browsing using Console...........................................................................31
7.2 MBean APIs for Message Browsing........................................................................33
7.3 Message Browsing using WLST.............................................................................38
7.3.1 Browse/get all the messages from queue “MyQueue1”...................................38
7.3.2 Get all the messages from “MyQueue1” that matches the selector
“JMSCorrelationID = ‘sent_to_MyQueue1’”............................................................39
7.3.3 Get all the messages from “MyQueue1” that are in a given state....................39
7.3.4 Navigating the cursor by one or more message at a time.................................40
7.3.5 Getting just one message from the queue using the JMSMessageID...............40
7.3.6 Printing the Messages.......................................................................................40
7.4 Caveats and Best Practices......................................................................................42
8 Message Manipulation....................................................................................................42
8.1 Move Messages.......................................................................................................42
8.1.1 Moving Messages using Console.....................................................................44
8.1.2 MBean APIs for Moving Messages..................................................................46
8.1.3 Moving Messages using WLST........................................................................47
8.1.4 Caveats and Best Practices...............................................................................48
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 2 of 87
8.2 Delete Messages......................................................................................................49
8.2.1 Deleting Messages using Console....................................................................49
8.2.2 MBean APIs for Deleting Messages.................................................................51
8.2.3 Deleting Messages using WLST.......................................................................52
8.2.4 Caveats and Best Practices...............................................................................52
8.3 New Message Production Using Console................................................................52
8.3.1 Caveats and Best Practices...............................................................................55
9 Message Export and Import............................................................................................55
9.1 Export Messages......................................................................................................55
9.1.1 Export Messages Programmatically.................................................................55
9.1.2 Export Messages using Console.......................................................................58
9.2 Importing Messages.................................................................................................60
9.2.1 Importing Messages Using Console.................................................................61
9.2.2 MBean APIs for Import Messages....................................................................63
9.3 Importing Messages using WLST...........................................................................64
9.3.1 Importing messages from MyQueue1 to MyQueue2.......................................65
10 Durable Subscription Management..............................................................................65
10.1 Managing Durable Subscribers using Console......................................................66
10.2 MBean APIs for Managing Durable Subscribers..................................................70
10.3 Durable Subscriber Management Using WLST....................................................71
10.3.1 Creating and navigating durable subscribers..................................................71
10.3.2 Getting the durable subscriber Runtime MBeans...........................................72
10.3.3 Deleting the durable subscriber......................................................................73
10.3.4 Message Management of the durable subscription.........................................74
11 Transaction Management..............................................................................................74
11.1 Transaction Management Using Console..............................................................75
11.2 MBean APIs...........................................................................................................77
11.3 Transaction Management Using WLST.................................................................80
11.3.1 Getting all the active Transaction IDs.............................................................80
11.3.2 Getting the Transaction status of a given Tx ID.............................................80
11.3.3 Getting the messages associated with Pending Transaction...........................81
11.3.4 Managing the messages associated with any given Transaction....................82
11.3.5 Forcing the transaction outcome to impact the message state........................83
12 Conclusion....................................................................................................................83
13 Errata.............................................................................................................................84
13.1 OOM (Out Of Memory) caveat.............................................................................84
13.2 UOO (Unit Of Order) caveat.................................................................................84
13.3 Pause/Resume caveat.............................................................................................84
14 Appendix A - References..............................................................................................85
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 3 of 87
1 Abstract
WebLogic JMS Runtime Administration, commonly known as “Message Management,”
consists of following groups of activities: Monitoring and managing the runtime state of
various JMS entities, Collecting Runtime Statistics of the JMS subsystem, Message
Browsing, Message Manipulation, Message Import/Export, Durable Subscription
Management, and Transaction Management. To support each of these activities
WebLogic Server offers various features and capabilities that includes a set of
programming APIs (exposed via JMX Runtime MBeans) and related Tools
(Administration Console and command-line utilities) that you can use to manage the
WebLogic JMS runtime environment. The purpose of this document is to provide an
overview of the JMS runtime infrastructure and related Tools, introduce basic concepts
around JMS runtime Administration, JMS Message Management and provide detailed
information about how to use various tools to perform the message management
operations in WebLogic Server. Both programming snippets/scripts for command-line
utilities and Console screenshots would be provided throughout this document as needed
to demonstrate various message management scenarios and capabilities of WebLogic
Server. Hence this document can serve as a reference guide for using command-line
utilities as well as Administration Console for WebLogic JMS message management.
The foundation of the WebLogic Server OAM infrastructure is built upon Java
Management Extensions (JMX)1 technology, which provides standards based API and
tools for building highly distributed, modular and dynamic management framework. The
implementation of this technology helps capture and organize various configuration and
runtime information in the form of JMX Management Bean APIs, or MBeans for short.
Once created, these MBeans can be exposed and accessed via various administration
tools including traditional command-line utilities, standalone GUI based application or
Web based Administration Console. For more information on JMX technology please see
http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/.
In WebLogic Server, both configuration and runtime information of server’s artifacts are
managed and monitored by accessing corresponding WebLogic JMX MBean APIs2. For
example, the configuration information of a WebLogic Server instance is managed using
“weblogic.management.configuration.ServerMBean” API and its runtime state is
monitored using “weblogic.management.runtime.ServerRuntimeMBean” API.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 4 of 87
Similarly, the configuration information of a JMSServer is managed using
“weblogic.management.configuration.JMSServerMBean” and its runtime state is
monitored using “weblogic.management.runtime.JMSServerRuntimeMBean” API.
Note that all the configuration MBean APIs belong to
“weblogic.management.configuration” package and all the runtime MBean APIs
belong to “weblogic.management.runtime” package of the server.
The WebLogic Server OAM infrastructure organizes these MBean APIs such that, the
organization would exactly reflect the hierarchical tree representation of a WebLogic
Domain. And hence, the root MBean for the configuration hierarchy tree is called
“weblogic.management.configuration.DomainMBean” and the runtime hierarchy tree
is called “weblogic.management.runtime.DomainRuntimeMBean”. So, to access any
of the MBeans (of type configuration or runtime), you have to first get access to the
Domain MBean of the tree type and navigate the MBean hierarchy until you reach the
MBean that is of interest. Note that there may not be one-to-one correspondence between
all the configuration MBeans and runtime MBeans, Certain Runtime MBeans may not
have the configuration MBean equivalent and vice versa. In WebLogic, these MBean
trees are also designed to have certain access control mechanism to either allow or
disallow the access of MBean nodes of the tree. And hence the WebLogic MBean trees
can be compared and treated analogous to a typical file system trees of an operating
system from the perspective navigation, manipulation and access control.
.
For the purpose of this paper, we limit the scope of the discussion to just JMS Runtime
MBeans and its hierarchy is as shown below.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 5 of 87
Domain
RuntimeMBean
1:M
Server
RuntimeMBean
1:1
JMS
RuntimeMBean
1:M
JMSServer
RuntimeMBean
1:M
JMSDestination
RuntimeMBean
1:M JMSDurableSubscriber
RuntimeMBean
1:M JMSConnection
RuntimeMBean
1:M JMSSession
RuntimeMBean
1:M
JMSConsumer
1:M
JMSPooledConnection RuntimeMBean
RuntimeMBean
1:M
JMSProducer
1:1
SAF RuntimeMBean
RuntimeMBean
1:M
SAFAgent
RuntimeMBean
1:M SAFRemoteEndpoint
RuntimeMBean
As you can see in the diagram, the root of the JMS Runtime MBean hierarchy begins at
“JMSRuntimeMBean” that has both “ServerRuntimeMBean” and
“DomainRuntimeMBean” as its ancestors. From this node in the tree, users can navigate
to the rest of the JMS runtime MBeans such as JMSServerRuntimeMBean,
JMSConnectionRuntimeMBean and so on.
Note that all of these MBeans are dynamically created and destroyed during runtime.
Some of them are long lived in the Server as long as their configuration equivalent is
actively deployed on the Server such as JMSServerRuntimeMBean and
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 6 of 87
JMSDestinationRuntimeMBean. The lifecycle of these MBeans are managed by the
WebLogic Server Administrator. Whereas some other MBeans such as
JMSConnectionRuntimeMBean, JMSSessionRuntimeMBean and
JMSConsumerRuntimeMBean are created to represent the runtime state of the JMS
Clients that are currently connected to the Server. The lifecycle of these MBeans are
determined by the JMS application itself and are destroyed as soon as the JMS Clients
disconnect from the Server. All of these MBeans for the JMS runtime artifacts are based
on simple data types and provide runtime statistics information as well as APIs for
administering the runtime state of the JMS entity.
However, JMS message management involves more than just administering the runtime
state of the configuration artifacts. It also involves the administration/browsing,
management, and manipulation of the actual JMS messages themselves that are currently
in the system. These messages are made up of complex data types as discussed below and
can have various transient states (see Table 2) while they are being produced or
consumed by applications. Also, messages can have vendor specific properties in addition
to the standard javax.jms.Message properties (see Table 1) that you may be interested
in for the management of the messages. To support this complex nature of JMS messages
and their management, WebLogic JMS includes an OAM façade around destinations,
messages, and consumers, and so forth, as extensions in WebLogic JMS3 which are
linked into and exposed via appropriate JMS runtime MBeans.
weblogic.jms.extensions.ConsumerInfo
weblogic.jms.extensions.DestinationInfo
The link between these extensions and the JMS runtime MBeans are made available
through a layer of special purpose Message Management MBean APIs called “Message
Cursors” as shown below.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 7 of 87
JMS
RuntimeMBean
1:M
JMSServer
RuntimeMBean
1:M
JMSDestination
RuntimeMBean
1:M
JMSDurableSubscriber
RuntimeMBean
JMSMessageManagement
RuntimeMBean
JMSMessageCursor
RuntimeMBean
MessageCursor
RuntimeMBean
Cursor
RuntimeMBean
For more details on WebLogic Server MBeans, see the WebLogic Server
MBeanReference at http://e-docs.bea.com/wls/docs103/wlsmbeanref/core/index.html.
For more details on JMS Message management extension, please refer to http://e-
docs.bea.com/wls/docs103/javadocs/weblogic/jms/extensions/package-summary.html
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 8 of 87
3 WebLogic Runtime Administration Tools
WebLogic Server offers various OAM tools for runtime administration of the Server. The
Web based Administration Console is very powerful and easy to use that enables the
users to perform the remote management using a web browser. There are also a set of
command-line utilities that can provide most of the administration capabilities and can be
used both interactively as well as part of a scripting environment. Both weblogic.Admin
and weblogic.WLST (WebLogic Scripting Tool)5 are widely known command-line
utilities for administering the WebLogic Server. In addition to these, JMS subsystem also
provides a special purpose command-line utility called weblogic.store.Admin that can
be used to manage the file based persistent store. All of these tools are built on-top of the
WebLogic JMX API infrastructure as described earlier. In addition to these readily
available administration tools, WebLogic Server offers programming APIs and Libraries
to users for building their own custom management utilizes and Administration Console
extensions.
For more details on how to build the custom management utilities and extensions, please
see
http://e-docs.bea.com/wls/docs103/custom_mgmt.html
For more details on WebLogic system administration and tools, please see
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/admin.html
For the purpose of this paper, only the Administration Console and weblogic.WLST are
discussed from the Runtime Administration perspective and are used to demonstrate the
example scenarios.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 9 of 87
Console Screenshot 1. Home page of WebLogic Administration Console
For details on how to use Console for various JMS runtime administration tasks, please
see
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/ConsoleHelp/pagehelp/Sum
marysummaryservicesjmssummarytitle.html.
As discussed earlier, WebLogic Server specific WLST commands are designed work by
navigating and manipulating the JMX MBean tree, which is analogous to navigating and
manipulating a typical file system tree environment. And hence WLST command verbs
such as ls(), cd() and pwd() are designed to work on the MBean tree in a similar
fashion to the file system tree.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 10 of 87
WLST can be used either in “online” mode, by connecting to the running Server or in
“offline” mode without connecting the running Server. When used in “online” mode, it
can be treated as a command-line equivalent of the Administration Console and enables
the users to monitor and administer the runtime environment on a live WebLogic domain.
For the JMS runtime management, WLST must be used in “online” mode and can use
any of the invocation techniques listed above.
java
[-Dweblogic.security.SSL.ignoreHostnameVerification=true
-Dweblogic.security.TrustKeyStore=DemoTrust]
weblogic.WLST
[-loadProperties propertyFilename ]
[-skipWLSModuleScanning ]
[[-i] filePath.py ]
The parameters that are specified inside the [ ] for both java and WLST
command-line are optional, when not specified WLST exhibit the default
behavior, which is the “offline” interactive mode and indicated by the prompt
“wls:/offline>”. Once started in this mode, users can enter “connect”
command to force the WLST to go into “online” interactive mode and proceed to
perform more administration tasks. As you can see in the example below, the
connect command takes three arguments, username, password and the
provider URL of the Administration Server.
java weblogic.WLST
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 11 of 87
Welcome to WebLogic Server Administration Scripting Shell
wls:/offline> connect('weblogic','weblogic','t3://localhost:7001')
Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'examplesServer' that
belongs to domain 'wl_server'
wls:/wl_server/serverConfig>
After successful connection to the Server, the WLST displays a log message
showing the Server Name and the domain name it is connected to. Also note that
there is Warning message displayed in the above example, since the connect
command specified a non-secure protocol in the provider URL.
Note that in interactive mode, after successful connection to the Server, WLST’s
prompt changes to “wls:/wl_server/serverConfig>” to indicate that the
WLST has entered into configuration management mode by navigating to the
“root” of the Server’s configuration MBean tree. By default, the WLST prompt
reflects the current location in the MBean tree, which can easily become large and
wrap around the screen. To eliminate this situation, WLST offers “prompt()”
command, when entered will toggle the prompt between simple form (wls:/>)
and expanded form (full path).
For Runtime Administration of the server, you need to navigate to the “root” of
the Server’s runtime MBean tree as shown below.
wls:/wl_server/serverConfig> serverRuntime()
Location changed to serverRuntime tree. This is a read-only tree
with ServerRuntimeMBean as the root.
For more help, use help(serverRuntime)
wls:/wl_server/serverRuntime>
wls:/wl_server/serverRuntime> prompt()
wls:>
wls:> prompt()
wls:/wl_server/serverRuntime>
The following command would take the user to the root of the JMS runtime
MBean tree (as described in Figure 1.)
wls:/wl_server/serverRuntime> cd ('JMSRuntime/examplesServer.jms')
wls:/wl_server/serverRuntime/JMSRuntime/examplesServer.jms>
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 12 of 87
All of the example WLST snippets shown throughout this document are based on
the assumption that the user has successfully connected and navigated to the root
of the JMSRuntimeMBean tree.
print – this is an overloaded command that would print out the value of the
argument. The argument can be an object, an attribute of an object or any standard
jython variable types or string literals.
pwd() – displays the full path of the current location in the MBean tree.
ls() – displays all the attribute values of the current management object (cmo)
cd() – changes the current location to the MBean node specified by the argument.
This command is designed to work like in a file system environment by treating
the MBean tree to a file system directory structure. Hence the argument “.” and
“..” are supported with same meaning as file system (“.” – denoting current
directory/node and “..” denoting parent directory/node) along with “/” as the
path separator.
Once navigated to the RuntimeMBean of interest, user can get more information
about that MBean and its attributes. Users can either use “ls()” to dump all the
attributes and values of the current MBean (cmo for short) or use the “getter” of a
particular attribute of that MBean. Both the Runtime MBean object itself or the
returned value of the MBean attribute can be stored in a local variable for later
access as shown below:
wls:/wl_server/serverRuntime/JMSRuntime/examplesServer.jms> print
cmo
[MBeanServerInvocationHandler]com.bea:Name=examplesServer,Type=Ser
verRuntime
wls:/wl_server/serverRuntime/JMSRuntime/examplesServer.jms>
prompt()
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 13 of 87
wls:/> ls()
wls:/> pwd()
'serverRuntime:/JMSRuntime/examplesServer.jms'
wls:/>ls()
dr-- Connections
dr-- JMSServers
-r-- ConnectionsCurrentCount 10
-r-- ConnectionsHighCount 10
-r-- ConnectionsTotalCount 14
-r-- HealthState
Component:null,State:HEALTH_OK,MBean:null,ReasonCode:[]
-r-- JMSServersCurrentCount 5
-r-- JMSServersHighCount 5
-r-- JMSServersTotalCount 5
-r-- Name
examplesServer.jms
-r-- Type JMSRuntime
5. After completing the administration tasks, you can exit out of WLST as shown
below.
wls:/> exit()
These basic steps outlined here need to be followed for every example WLST snippets
shown throughout this document to avoid the repetition.
Most of the example WLST scripts shown in this paper are based on a simple JMS
configuration that is created using the following steps.
Step 2. Invoke WLST to run the following snippet (configjms.py) to create the basic JMS
configuration.
b. java weblogic.WLST configjms.py
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 14 of 87
# import the necessary packages
import sys
from java.lang import System
else:
# create the JMSServer instance named “MyJMSServer1”
jmsserver1mb = create('MyJMSServer1','JMSServer')
# and target the JMSServer “MyJMSServer1” to “myserver”
jmsserver1mb.addTarget(servermb)
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 15 of 87
jmsqueue1 = theJMSResource.createQueue('MyQueue1')
jmsqueue1.setJNDIName('wlst.mgmt.jms.MyQueue1')
jmsqueue1.setSubDeploymentName('DeployToJMSServer1')
try:
# try to save the configuration changes
save()
# activate the configuration changes and wait for its completion
activate(block="true")
except:
# on error log error message and the exception trace
print "Error while trying to save and/or activate!!!"
dumpStack()
Also, the example snippets assume that messages are already produced on the
destinations/durable subscribers and are available in various states. (See Table 2 for more
info).
For example, the underlying persistent store that holds the persistent messages might run
out of disk space or experience network issues (in case of JDBC Store) making it
unavailable for service.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 16 of 87
Second example could be where, the message consumer application might not be able to
keep up with the incoming rate of the messages, leading to more message backlog in the
server and more server resource use that will eventually lead to conditions like out of
memory error situations.
Third example could be where, the system has received a “poison” message that cannot
be handled by the consumer application or a “badly” behaved consumer application that
causes the repeated redelivery of the same message leading to server “thrashing” and
interruption of the message flow.
Yet another situation can be where, the UOO7 (Unit Of Order) messages are processed as
part of a global transaction and the one of the participant was not able to successfully
complete the transaction and hence causing those messages “stuck” in the system and
stalling the processing of the entire UOO.
All of these situations need to be actively monitored and detected to avoid any
interruption to the messaging service.
The situation described in the first example above, is the classic situation of the entire
subsystem failure and can be automatically handled via “Service Migration” feature of
the WebLogic Server.
The situations described in the rest of the examples can be easily handled by monitoring
and performing simple runtime state change operations and message manipulation
operations via either Administration Console or WLST.
To handle the situation described in the second example above, you can the JMS runtime
administration feature called “pause/resume messaging operations”. You can change the
running state of the problematic destination to “production paused” in WLST by invoking
the command “pauseProduction()” after navigating to the corresponding destination
runtime MBean which will effectively prevent any new messages being produced to that
destination thus allowing the consumers to catch up with the backlog. More on the
“pause/resume” feature is discussed in the following sections.
The situation described in the third example can be handled by pausing both production
and consumption on the problematic destination runtime and manually moving the
“poison” message to an error destination for further investigation and resume both
production and consumption to continue.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 17 of 87
Finally, the scenario described in the last example can be handled by transaction
management as explained later in this document in section 11.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 18 of 87
For detailed console steps for controlling all the destinations on a JMSServer, please see:
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/ConsoleHelp/taskhelp/jms_
servers/ConfigureJMSServerControl.html
New Message Production – This process represents any new message production
by new or existing producers on a destination.
Each of these messages processing operation has its corresponding pause and resume
control APIs as described in the table below.
Note these operations can be performed at both JMSServer level or at the individual
Destination level. When performed on the JMSServer, the operation will impact all the
destinations that are hosted on that JMSServer.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 19 of 87
For more information on the APIs, please see
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/wlsmbeanref/mbeans/JMSS
erverRuntimeMBean.html and
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/wlsmbeanref/mbeans/JMS
DestinationRuntimeBean.html
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 20 of 87
# note that the “cmo” is now pointing to the JMSServer “MyJMSServer1”
cmo.pauseProduction()
Also, note that runtime state change using these APIs is not going to affect the start-up
behavior configured on the JMSServer or Destination. In other words, when the
Destination or JMSServer gets redeployed, it will start with appropriate message
processing state as configured.
As JMSServer acts as a container for the destinations, some of the runtime administration
operations on the JMSServer would also affect the destinations as well and pause/resume
operation is one such example.
There may be cases where a group of destinations that are hosted on a single JMSServer
need to be paused or resumed together for messaging operation, and can be easily and
conveniently done by simply performing the operation on the hosting JMSServer once
rather than repeating the same operation on every destination. This is common in
scenarios where the administrator wants isolate a problematic destination among the
group of destinations. To do so, the administrator can stop all the messaging operations
on a given JMSServer first by calling the appropriate “pause” operation and resume the
messaging operation gradually by calling “resume” on individual destination one at a
time until the issues is detected.
For more details on pausing and resuming the message processing operations, please see
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jms_admin/troubleshoot.ht
ml#wp1127322
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 21 of 87
As part of the JMS runtime administration, you may want to gather metrics about the
system that maybe used to analysis. Careful analysis of the metrics would aid the
administrator in many situations including but not limited to:
Problem identification and resolution – For example monitoring queue depth may
indicate that the messaging rate of the system and would help identify slow running
producers or consumers and/or stuck messages.
Capacity planning – queue depth and the messaging rate are key indicators for sizing the
resources to handle the applications’ load, scalability and performance requirements of
the system appropriately.
In WebLogic, top level JMS runtime statistics on any given Server instance can be
obtained from the JMSRuntimeMBean of that Server that include both connection level
(called frontend) and at JMSServer (called backend) level information.
The frontend statistics include how many active connections, sessions, producers and
consumers are active in the system.
The backend statistics include how many JMSServers are active, how many destinations
are active on each of the JMSServer and various message related metrics on those
JMSServers and destinations.
Note that all of these statistics information is dynamic and only represents the
information about that entity since that entity was last reset/booted/restarted. In other
words, all of the runtime statistics will be reset to 0 or appropriate current values every
time that entity is restarted. Restarting a server instance resets all the statistics
information both the frontend and backend that exists on that server instance.
Current Count - Indicates that the current value of the specified attribute/entity
since the last boot/restart
High Count – Indicates that highest value of the specified attribute/entity at any
one time since the last boot/restart
Total Count – Indicates that the total value of the specified attribute/entity since
the last boot/restart
The complete MBean hierarchy of the JMS runtime is described in section 2 and in
Figure 1.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 22 of 87
Console Screenshot 4. JMS Message Statistics information on a JMSServer
To get the message statistics of a destination using console, you can either navigate to the
runtime monitoring page of the JMSServer that is hosting the destination and clicking on
the “Active Destinations” tab (screenshot 6) or navigate to the specific JMS destination
runtime MBean by navigating through the JMS module where the destination is
defined/deployed (screenshot 7). Note that in the first approach, the table will list all the
statistics information for all the destinations that are hosted on that JMSServer.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 23 of 87
Console Screenshot 6. JMS Message Statistics information on a destination
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 24 of 87
current active connections from
this WebLogic Server instance.
JMSServerRuntimeMBean[] Returns an array
getJMSServers() JMSServerRuntimeMBeans of the
currently deployed JMSServers on
this WebLogic Server instance.
HealthState getHealthState(); Returns the health state of the JMS
Service on this WebLogic Server
instance.
The following table shows the message related statistics from a destination runtime
MBean. Note that the message statistics information can be obtained based on the count
and/or the size (total bytes) of the messages that are in the system. In addition to the
count and size, you can also obtain information about how long the given destination was
in “threshold” condition.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 25 of 87
sent in a transaction and not
committed, or that have been
received and not committed or
acknowledged.
Public long getBytesHighCount(); The peak number of bytes on the
destination since the last reset.
Public long getBytesReceivedCount The number of bytes produced on
this destination since that reset.
Long getBytesThresholdTime(); The amount of time this
destination was in the bytes
threshold condition since the last
reset.
wls:/wl_server/serverRuntime/JMSRuntime/examplesServer.jms>
The following snippet shows how to find out the “queue depth” of a given destination.
# get the messages current count value and store it in a var called
“mcc”
mcc = cmo.getMessagesCurrentCount()
# get the messages pending count value and store it in a var called
“mpc”
mpc = cmo.getMessagesPendingCount()
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 26 of 87
# Add both messages current count and messages pending count and store
it in
# local var called “queue_depth”
queue_depth = mcc + mpc
# print out the value of the queue depth for the destination named
“MyQueue1”
print queue_depth
WLS Snippet 4 – Calculating the queue depth of a destination using message statistics
The following snippet shows how to calculate the total number of messages on a given
JMSServer.
# get the messages current count value and store it in the local var
“jsmcc”
jsmcc = cmo.getMessagesCurrentCount()
# get the messages pending count value and store it in the local var
“jsmpc”
jsmpc = cmo.getMessagesPendingCount()
# add both messages current count and messages pending count values to
find
# out the total number of messages available on JMSServer “MyJMSServer1”
total_msgs = jsmcc + jsmpc
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 27 of 87
To find the queue depth of a given Destination or a JMSServer, you need to can be
calculated by adding both “MessagesCurrentCount” and “MessagesPendingCount”
values.
In addition to the message statistics information, the JMS destination runtime also has the
information about the consumer counts. So, to find out whether a given destination has
active consumers or not, you need to navigate to the destination runtime MBean and use
the appropriate getters or use the console page as shown in screenshot 7.
The selector is a regular boolean expression consists of a string with syntax similar to
where clause of an SQL select statement. Selector can include various attributes
associated with the messages headers and properties. WebLogic JMS allows the users to
create selector expression based on JMS message header fields and or property fields. In
addition to the standard JMS message header fields, you can also use the WebLogic
specific system properties such as JMS_BEA_UnitOfOrder, JMS_BEA_Size and
JMS_BEA_State. See the Table 1 below for WebLogic specific JMS message properties.
Contents of the message body cannot be used as part of the filter expression except for
XMLMessage type. For XML message types, WebLogic provides a special syntax called
“JMS_BEA_SELECT” based on XPATH expression in addition to the standard SQL select
syntax. The XML selector can be used to select messages based on the content of the
XML message body.
Get all the messages that are in the queue with priority great than 5
“JMSPriority > 5”
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 28 of 87
Get all the messages that belong to the unit-of-order “BLUE”
“JMS_BEA_UnitOfOrder LIKE ‘BLUE’”
Get all the messages that are pending as part of a receive transaction
“JMS_BEA_State LIKE ‘receive transaction’”
The following table identifies the WLS-specific metadata properties that can be used for
message selection or sorting in addition to the standard JMS Message header properties.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 29 of 87
In addition to the WebLogic-specific header properties mentioned above, there are
additional attributes about the message along with the actual messages that are captured
in the weblogic.jms.extension.JMSMessageInfo extension. One message attribute
holds information about the current state of the message, as shown in the table below:
This concept is very useful in effectively managing a large number of messages in the
system without using large amount of server resources.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 30 of 87
For more details on message filtering, please see
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jms/manage_apps.html#wp
1186875
7 Message Browsing
With the Message Browsing features, you can programmatically or administratively
obtain a list of messages on a given destination that matches certain selection criteria for
viewing its contents without really consuming them off of the destination. This feature is
very useful in situations, where the Administrator would like to browse through the
destination looking for particular message(s) to isolate problem causing messages. This
feature is implemented using the messaging concepts described above.
Note that since the cursor is just a snapshot of a live destination in time, it can easily
become “stale” if the messages are produced and consumed on a on that destination after
the cursor is created. To prevent the browsing of outdated messages, you can “pause” the
message production and consumption (see section 4. above) on the destination prior to
creating the cursor.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 31 of 87
Console Screenshot 7. Message Browsing Step 1
Once enabled, clicking on the “Show Messages” button would display a table all the
messages that are available on that destination as shown below. To display a filtered list
of messages, you can enter a valid ‘selector” expression in the “Message Selector” text
box and the click “Apply” button.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 32 of 87
7.2 MBean APIs for Message Browsing
Various cursor APIs (getMessages) are available on JMSServerRuntimeMBean,
JMSDestinationRuntimeMBean and DurableSubscriberRuntimeMBean. This allows the
users to create, sort and navigate message cursors and enables the users to browse the
messages that are available on all the destinations of given JMSServer, the messages on a
single given destination or the messages that are associated with a particular durable
subscription.
These APIs include a selection parameter that enables you to select messages using a
JMS message selector expression to fill the cursor with messages that meet specific
selection criteria. After you fill the cursor, you can then browse through messages in the
cursor.
When a cursor is created, a handle representing the cursor is returned to the user. No
protection mechanism exists to prevent accessing the cursor from more than one
management client. If you access a cursor from multiple management clients, the
behavior on any of those clients is undefined.
Cursors are long lived entities that consume resources on the server. As a safeguard
mechanism, cursors are created with an expiration timeout. If the cursor is not accessed
during the specified timeout period, the cursor’s handle will be invalidated and all
related server resources will be released.
The following table lists the message browsing APIs that are common to
JMSServerRuntimeMBean, JMSDestinationRuntimeMBean and
JMSDurableSubscriberRuntimeMBean.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 33 of 87
attributes on which to sort.
@param ascending Determines
whether the sort of the
corresponding fields element is
in ascending or descending
order.
@return The new position of the
message specified by the start
parameter.
@throws ManagementException
Thrown when an internal JMS
error occurs while processing
the request.
@see
javax.management.openmbean.Compo
siteData
CompositeData getMessage(String Given a JMS message ID this
cursorHandle, String messageID) method returns the corresponding
throws ManagementException; message from the queue. If no
message with the specified
message ID exists on the
destination, a null value is
returned.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 34 of 87
Long getCursorStartPosition(String Returns the cursor start
cursorHandle) throws position in the result set.
ManagementException;
@param cursorHandle The cursor
handle.
@return The cursor start
position.
Long getCursorEndPosition(String Returns the cursor end position
cursorHandle) throws in the result set.
ManagementException;
@param cursorHandle The cursor
handle.
@return The cursor end position.
CompositeData[] getItems(String Returns an array of items from
cursorHandle, Long start, Integer the specified cursor location.
count) throws ManagementException; The new cursor start position
will be the location after the
old cursor end position. The
size of the array returned is
determined by the count
argument. An array smaller than
the "count" value is returned if
there are fewer items from the
specified start position to the
end of the result set.
A null value is returned if the
size of the return array is
zero. In this case, the cursor
position will not change.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 35 of 87
end of the result set.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 36 of 87
@param selector A valid JMS
message selector.
@exception
weblogic.management.ManagementEx
ception Thrown when the provided
message selector contains
invalid syntax, or when an
internal error is encountered.
String getMessages(String selector, Queries messages on the queue
Integer timeout) throws according to the provided
ManagementException; message selector and returns a
message cursor representing the
result set.
@exception
weblogic.management.ManagementEx
ception Thrown when the provided
message selector contains
invalid syntax, or when an
internal error is encountered.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 37 of 87
Given a JMS message ID this
CompositeData getMessage(String
method returns the corresponding
messageID) throws
message from the queue. If no
ManagementException;
message with the specified
message ID exists on the
destination, a null value is
returned.
@exception
weblogic.management.ManagementEx
ception Thrown when an error
occurs while performing the
query.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 38 of 87
WLST Snippet 6 – Browse/get all the messages on a queue
7.3.2 Get all the messages from “MyQueue1” that matches the selector
“JMSCorrelationID = ‘sent_to_MyQueue1’”
# create a cursor to get all the messages in the queue
# that matches the selector expression,
# pass in the selector expression and long value for cursor timeout
cursor1=cmo.getMessages(‘JMSCorrelationID
LIKE \’sent_to_MyQueue1\’’,9999999)
7.3.3 Get all the messages from “MyQueue1” that are in a given state
The following snippet would get all the UOO messages that are not available for
consumption yet, and are in a state called “ordered” (bitmask 16).
Note: Please see the Table 2 for different message state bitmask values
# create a cursor to get all the UOO messages from the queue that
# belongs to the UOO named “my_uoo” that are currently
# in “ordered” state.
# Note 1: The third argument value represents the ‘state’.
# Note 2: To get all the ordered messages that may belong
# to more then one UOO, pass the first argument as ‘true’
cursor1=cmo.getMessages(‘JMS_BEA_UnitOfOrder
LIKE \’my_uoo\’’,9999999,16)
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 39 of 87
# print all the messages’ contents
print msgs
7.3.5 Getting just one message from the queue using the JMSMessageID
At times, you may want to just get one message using the JMSMessageID directly from
the queue, without creating the message cursor.
WLST Snippet 10 – Get one messages from the queue directly without using the cursor
The following shows the message content in “CompositeData” format when printed
using “print” command. Note that if the print argument represents an array of messages
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 40 of 87
(returned by: getItems(), getNext() or getPrevious()), then the all the messages
would be printed at once.
array(javax.management.openmbean.CompositeData,
[javax.management.openmbean.CompositeDataSupport(compositeType=javax.man
agement.ope
nmbean.CompositeType(name=MessageInfo,items=((itemName=BodyIncluded,item
Type=javax.management.openmbean.SimpleType(name=java.lang.
Boolean)),
(itemName=ConsumerID,itemType=javax.management.openmbean.SimpleType(name
=java.lang.String)),
(itemName=DestinationName,itemType=javax.management.openmbean.SimpleType
(name=java.lang.String)),
(itemName=Handle,itemType=javax.management.openmbean.SimpleType(name=jav
a.lang.Long)),
(itemName=MessageSize,itemType=javax.management.openmbean.SimpleType(nam
e=java.lang.Long)),
(itemName=MessageXMLText,itemType=javax.management.openmbean.SimpleType(
name=java.lang.String)),
(itemName=SequenceNumber,itemType=javax.management.openmbean.SimpleType(
name=java.lang.Long)),
(itemName=State,itemType=javax.management.openmbean.SimpleType(name=java
.lang.Integer)),
(itemName=VersionNumber,itemType=javax.management.openmbean.SimpleType(n
ame=java.lang.Integer)),
(itemName=XidString,itemType=javax.management.openmbean.SimpleType(name=
java.lang.String)))),
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 41 of 87
</mes:Properties>
</mes:Header>
</mes:WLJMSMessage>, SequenceNumber=1, State=1, VersionNumber=1,
XidString=null})])
8 Message Manipulation
In addition to message browsing, the Message Management features and capabilities in
WebLogic Server enable you to administratively move and delete messages from JMS
destinations.
When moving or deleting messages, you must first select a list of messages usually by
means of “message selector”.
Users might want “move” messages for various reasons. For example, users might want
to free up some of the resource usage on an overloaded source server temporarily by
moving a set of (large?) messages from that server (source destination) to another (target
destination) and moving them back after short while to avoid the whole server falling
over and disrupting the service. The classic use case is where a destination or JMSServer
has reached its maximum “quota” limit for the number messages (or total bytes), has no
active consumers draining from that destination and producers are continue to produce
(with or without “quota blocking send”) onto that destination. In this scenario, the
message production onto that destination would eventually fail with
“javax.jms.ResourceAllocationException”. This issue can be addressed by
temporarily moving the messages to another destination and eliminate the disruption to
the message production.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 42 of 87
Another example for “move” would be the cases, where the user wants to manually move
a particular problematic message or set of messages permanently onto an “error”
destination for later investigation. In both cases, users can either use RuntimeMBean
APIs, WLST or Administration Console to perform the move operations.
However, users must be aware of certain pre-conditions that need to be met for a
successful move operation. Also you must be aware of how a certain runtime
attributes/states on the messages as well as on the source/target destinations would be
affecting, both before and after the “move” operation is performed.
- Message states:
o A message can only be moved if its current state is “visible”,
“delayed” or “ordered” (see Table 2.1.2 Message States above).
o “In-flight” (pending) messages that are being produced (uncommitted
transactional send) or consumed (un-acked/uncommitted receive)
cannot be moved. (See Transaction Management below).
o When a UOO message is moved, it will get added to the same UOO on
the target destination as though it was produced programmatically; it
will be added to the end of the ordered sequence if one already exists.
- Destination States/Types:
o Messages cannot be moved to a target destination that is in the
“production paused” state.
o Target destination cannot be a SAF imported destination or a
distributed destination. However a distributed destination member can
be selected as the target destination for the move.
o When the target destination is a topic, then the message will be
distributed to all the subscribers matching the selector. Messages
moved to an individual durable subscription will be made available to
that individual subscriber only.
- Message States:
o All the message state information would be preserved on the target
destination, except when the UOO messages got moved, see “Caveats”
for more information.
o The Move operation preserves all the message information including
header properties and user properties except the following: (Confirm
with Alex/Team)
The delivery count on the message will be reset to “0” when it
is placed on the target destination. In other words both the
Message RedeliveryLimit and Message RedeliveryCount
values are not preserved during the move.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 43 of 87
Messages with PERSISTENT delivery mode will be downgraded
to NON-PERSISTENT if the target destination does not support
persistence
o All the messages that moved and are in “visible” state would be
available for consumption immediately.
- The following message statistics information would get updated during the
move operation.
o MessagesMovedCurrentCount – would get updated on the source
destination to reflect the number of messages that got moved from this
destination since the last restart/boot.
o All the message runtime statistics (discussed in section 5.1.2 above) on
the target destination (and the durable subscription) would get updated
to reflect the number of messages that moved onto that destination as
if they were directly produced on that destination.
Console provides a page flow for performing message move. The first step is to navigate
to the source destination’s monitoring page (which is different from the first step
mentioned in using WLST to perform the move messages) and display messages in the
table form (see screenshot 7.3 above). Once you are in the “Summary of JMS Messages”
page, you see the options for message “move” along with other message manipulation
operations. From this screen you can either move all the messages or a selected list of
messages to a different destination. To select a list of messages for move, you can use the
“checkbox” in front of each message as shown in the following screenshot.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 44 of 87
Console Screenshot 9. Message Move Step 1
The next step in the process is to click on the “Move” button which drops down to
“Move” and ‘Move All”. For this example, we are going to use the “Move” option to
move the select list of messages. Once the “Move” is clicked, the next couple of pages
allow the user to select the “Target” JMSServer/destination for move as shown in the
screenshot below:
In this example, the target JMSServer is selected as ‘MyJMSServer2” and the next page
list all the available destinations from that JMSServer to select as shown in the next
screenshot.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 45 of 87
Console Screenshot 11. Message Move Step 3
The moved messages can be seen on the target destination (MyQueue2) as shown below.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 46 of 87
8.1.2 MBean APIs for Moving Messages
API Signature Description
Moves the set of messages that
Integer moveMessages(String
match the specified selector to
selector, CompositeData
the target destination. The move
targetDestination) throws
operation is guaranteed to be
ManagementException;
atomic for the selected messages.
@exception
weblogic.management.ManagementExce
ption Thrown if an error occurs
while processing the request. The
selected messages will remain on
the source destination.
Same as the previous API, except
Integer moveMessages (String
that this takes the third
selector, CompositeData
argument, “timeout”, indicating
targetDestination, Integer timeout)
how long to wait for the move
throws ManagementException;
operation to complete.
This following example shows how to move a particular message that matches a selector
from “MyQueue1” to “MyQueue2” directly using the destination runtime MBeans.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 47 of 87
# first navigate to the target destination “MyQueue2”
cd (‘MyJMSServer2/Destinations/MyJmsSystemResource!MyQueue2’)
# print how many messages are moved by the above move operation
print count
# the move operation is also tracked in the system so you can get the
total
# number of moved messages from this destination since the destination
was
# last booted.
movedcurrentcount=cmo.getMessagesMovedCurrentCount()
# print how many messages are moved since the last boot
print movedcurrentcount
WLST Snippet 12 – Move messages that matches the selector from one queue (source) to
another (target) queue
Note 1: The “Move” message operation is done transactionally and hence either all the
messages that match the selector will be moved or none of them will be moved. This in
some cases may block the operation indefinitely (for example a large backlog of big
messages). To overcome this situation, you can specify the “timeout” value for this
operation such that the “move” operation would terminate after the specified timeout.
Note 2: Also, for the move operation the “target” destination has to be passed in as an
argument in the form of “CompositeData” representation. So, the first step to perform
“move” operation in WLST is to navigate to the target destination and get the
DestinationInfo (which is in the form of CompositeData) and store it in a local variable
and then pass it as the argument to the moveMessages API.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 48 of 87
As a best practice, messages should only be moved if the source destination is in
“consumption paused” state (see section 4 above) to prevent consumers from consuming
messages that are currently selected for moving to another destination.
Message move operation is performed in global transaction to avoid message loss in the
event of system failure while performing the move. A system failure during the
processing will result in an exception being thrown to the client. If a global transaction
context exists on the thread processing the move message operation, the transaction will
be suspended before the move operation, and resumed after it completes.
Currently, when UOO messages got moved (as whole or partially) and if the target
destination already has messages for the same UOO, then the moved messages would be
added to the end of the existing message list and the first message from the moved list
would be marked as state “ordered” regardless of its original state. If the target
destination does not have any messages for the same UOO, the first messages from the
moved list would marked as state “visible” and immediately available for consumption
and this would break ”ordering” of UOO, especially when partial list of UOO messages
got moved. At the same time, on the source destination, the next message in the UOO list
that was previously in an “ordered” state would be changed to state “visible” and
becomes available for consumption immediately. Note that moving back the previously
moved messages to the original destination exhibits the same behavior and hence they get
appended to the end of the message list of an existing UOO.
Also, performing the “move” operation of the UOO messages can cause additional
problems regardless of whether any UOO messages remain in the original destination or
not and whether the UOO messages got moved as “whole” or “part”. Since the
destination for producing the UOO messages is pre-selected at the very first message
“send” operation and all the subsequent “send” operations will get directed to the same
destination based on some “loading balancing/routing algorithm” to ensure the
guaranteed ordering of those UOO messages. Today, there exists some disconnect
between administrative message “move” operation and the underlying load
balancing/routing machinery. So, even when the move is performed for the “whole” list
of UOO messages, any new UOO messages produced for the same UOO could still load-
balance to the original destination - which effectively splits the UOO and its ordering. For
path service based routing of UOO, the path service does not know about the move, or at
most may figure out that the old destination doesn't own the UOO (but not where the
UOO was moved). Hash based routing will always send new messages for the UOO to
the same place. Both of these cases may potentially lead to corrupted UOOs.
And hence, users must try to avoid performing “move” operations of UOO messages for
the reasons explained above.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 49 of 87
Similar to the message “move” feature described above, the message “delete” feature
allows the users to delete certain messages both programmatically and administratively
using the runtime MBean APIs and Console. Again, users might want perform the
message “delete” for various reason such as removing a problematic “poison” message
from the destination. Also, similar to moving messages, deleting messages also enforces
certain pre-conditions to be met and may affect certain message states and/or destination
runtime statistics attributes.
To delete messages from a destination using Console, you need to first navigate to that
destination’s monitoring page and select that destination and click on “Show Messages”
(see screenshot 7.3 above) button to display the “Summary of JMS messages” page that
has the “Delete” option. Users can then either use “Delete” or “Delete All” option to
delete a selected list of messages or to delete all the messages available on that
destination as shown in the screenshot below:
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 50 of 87
Console Screenshot 13. Message Delete Step 1
Once either “Delete” or “Delete All” is clicked, the next page would display a
confirmation page containing all the selected messages’ IDs, before performing the final
action as shown below.
By Clicking “Yes” in the confirmation, the actual delete operation is performed the
following page will be displayed to confirm the successful completion with a log
message indicating how many messages got deleted. Note that in this example, we have
deleted all the messages from the destination and hence the “JMS Messages” table is
shown empty.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 51 of 87
Console Screenshot 15. Message Delete Step 3
The APIs for deleting messages are available on the JMSDestinationRuntimeMBean and
JMSDurableSubscriberRuntimeMBean.
@exception
weblogic.management.ManagementExcep
tion Thrown if an error occurs
while processing the request. The
selected messages will remain on
the source destination.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 52 of 87
8.2.3 Deleting Messages using WLST
This example shows how to delete a set of messages that matches a selector expression
from “MyQueue1”.
# Also, you can get the current deleted messages count as follows
# this value returns the total count of all the messages deleted from
# this destination since the last time it was booted
deletedcurrentcount = cmo.getMessagesDeletedCurrentCount()
WLST Snippet 13 – Delete messages from a queue that matches the selector
You should pause a destination for message consumption before deleting the messages
from it to prevent consumers from consuming messages that are selected for deletion.
The message delete operation is NOT performed under a global transaction, hence in the
event of a system failure, it is possible to have partial outcome whereby only a portion of
the messages matching the selector have been deleted.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 53 of 87
In addition to the “Move” and “Delete” of messages, WebLogic Console also offers a
way to create and produce new messages (of TextMessage type) administratively on a
given destination using the Console. Note that there is no runtime MBean APIs or the
WLST equivalent exists for new message production and hence you need to follow the
standard javax.jms programming APIs to produce new messages programmatically.
To produce messages administratively using Console, you need to first navigate to the
runtime monitoring page of a given destination and select that destination from the table
and click “Show Messages” (see screenshot 7.3 above). From this page users can click
on “New” button as shown below, would take to the next page where users can populate
the message contents.
The message creation page displays some of the standard javax.jms.Message header
fields and a text box to enter the message body as shown in the screenshot shown below.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 54 of 87
Console Screenshot 17. New Message Production Step 2
After populating the appropriate values, users can click on the “OK” button to produce
this message on the destination and completes the new message production. The next
page will display the confirmation message along with the “JMS Messages” table holding
the newly produced message as shown in the screenshot below.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 55 of 87
8.3.1 Caveats and Best Practices
The new message production functionality available on the Console currently only
supports “TextMessage” with a limited set of message header/property values editing.
Today, the “export” functionality is available only via Administration Console, whereas
the “import” functionality is available both via the Console as well as through the runtime
MBean APIs and WLST.
As mentioned earlier, currently there is no runtime MBean APIs available to perform this
operation programmatically. But here is the pseudo code to implement this functionality.
/**
* pseudo code for JMS Message Export operation based on
* current implementation in the Administration Console
*/
import java.io.File;
import java.io.FileOutputStream;
import java.io.OutputStreamWriter;
import java.io.BufferedWriter;
import java.io.Writer;
import java.io.IOException;
import java.util.ArrayList;
import java.util.Collection;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 56 of 87
import org.w3c.dom.Node;
import weblogic.apache.xerces.dom.DocumentImpl;
import weblogic.apache.xml.serialize.OutputFormat;
import weblogic.apache.xml.serialize.XMLSerializer;
import weblogic.management.runtime.JMSDestinationRuntimeMBean;
import weblogic.management.runtime.JMSDurableSubscriberRuntimeMBean;
import weblogic.management.runtime.JMSMessageManagementRuntimeMBean;
import javax.management.openmbean.CompositeData;
import weblogic.jms.extensions.JMSMessageInfo;
import weblogic.jms.extensions.WLMessage;
import weblogic.messaging.kernel.Cursor;
BufferedWriter bw = null;
try {
bw.write(xmlDeclaration);
bw.newLine();
bw.write(exportStart);
bw.newLine();
bw.newLine();
bw.write(indent);
of.setIndenting(true);
of.setLineSeparator("\n"+indent);
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 57 of 87
of.setOmitXMLDeclaration(true);
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 58 of 87
super.printText(text,true,unescaped);
}
};
}
Console provides a page flow for performing the message export operation. As always,
the first step for performing the message operation is to navigate to the destination’s
monitoring page and clicking on the destination name from the table, then clicking the
“Show Messages” button to display the existing messages.
In this page the “Export” button is displayed with two options: “Export’ and “Export All”
as shown in the screenshot below:
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 59 of 87
When the “Export All” option is selected, the following page would display a file
selection feature, allowing the user navigate the local file system directory structure and
select a directory or a XML file to which the messages would be exported. By default, the
Console assigns the file name as “jmsmessages.xml” under the “root” directory of the file
system where the WebLogic Domain is configured. The screenshot below illustrates this
page.
Once the appropriate file name is selected for export, clicking “OK” will take you to the
confirmation screen as shown blow:
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 60 of 87
Console Screenshot 21. Export Message Step 3
Note the log message indicates “Selected JMS Messages have been exported”, and when
“Export All” option is used without selecting any messages, then all the messages from
that destination would get exported to the file.
The contents of the XML file containing a single exported message is shown below:
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 61 of 87
</mes:Header>
- <mes:Body>
<mes:Text>four</mes:Text>
</mes:Body>
</mes:WLJMSMessage>
</JMSMessageExport>
And hence, while importing onto the same destination where the messages are originally
exported from, users can choose to “replace” the existing messages with ones that are in
the XML file. Note that the “replace” option is only available through MBean APIs and
not in Console.
The following table lists the message properties are affected by the import operation
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 62 of 87
N
JMS_BEA_UnitOfOrder N
JMS_BEA_Size Y
JMS_BEA_SequenceNumber Y
JMS_BEA_DeliveryTime N
JMS_BEA_RedeliveryLimit N
JMSXDeliveryCount N
Note that if you want to preserve more of the message properties, consider moving the
messages to another destination instead of exporting and importing messages.
Importing messages from an XML file onto a JMS destination follows similar steps as
export. First step is to navigate to the JMS destination (or Durable subscriber) monitoring
page onto which you want to import the messages as shown below.
In this example, we are going to import messages onto “MyQueue2”, which current has
no messages. By clicking on the “Import” button, the Console displays a File browsing
dialog as shown below which allows the user to select the appropriate XML file that has
originally exported messages.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 63 of 87
Console Screenshot 23. Import Message Step 2
After selecting the XML file, you need to click “Ok” to being the import processing.
After successful completion of the importing, the Console displays the confirmation page
along with the messages in the table as shown below.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 64 of 87
9.2.2 MBean APIs for Import Messages
@exception
weblogic.management.ManagementExce
ption Thrown if an error occurs
while processing the request. The
selected messages will remain on
the source destination.
Also, there are APIs added to the WLS JMS extensions as listed below to support the
message import/export operations.
On weblogic.jms.extensions.WLMessageFactory
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 65 of 87
null then this is the same as
ClassNotFoundException;
calling the createMessage method
without argument.
@exception
weblogic.management.ManagementExce
ption Thrown if an error occurs
while processing the request. The
selected messages will remain on
the source destination.
On weblogic.jms.extensions.WLMessage
# next find the cursor size (total number of messages in the cursor)
size=cmo.getCursorSize(cursor1)
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 66 of 87
msgs=cmo.getItems(cursor1, 1, size)
# now import all the messages that are already stored in “msgs” above
# note that the second argument “replaceOnly” is only allowing “false”
# at this moment and hence no is indicating “replaceOnly” is
cmo.importMessages(msgs,false)
Similar to other features discussed above, these capabilities are exposed both via
programmatic APIs as well as the Administration Console.
Since the durable subscribers are associated with the Topic destinations, the first step in
the management process is to navigate to the appropriate Topic’s monitoring page as
shown below.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 67 of 87
Console Screenshot 25. Creating New Durable Subscriber – Step 1
The “Durable Subscribers” on this page lists a table of durable subscribers that are
currently exist on this topic. The buttons above and below the table allow the users to
take various actions on the durable subscribers listed.
To create a brand new durable subscriber administratively, you need to click on the
“New” button which will display the page for entering the information about the
subscriber as shown below.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 68 of 87
After validating the information entered, the next page would display the confirmation
message indicating the successful creation of the durable subscriber based on the input
and the table would list the information as shown below.
At this time, both the “Delete” and “Show Messages” buttons are enabled. By selecting
any of the durable subscribers from the table and clicking on the “Show Messages”
would display the messages associated with that durable subscriber as shown below.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 69 of 87
Console Screenshot 28. Browsing Messages on a Durable Subscriber
While you are at this page, you can perform further message management operations
such move, delete, import and export of this durable subscriber’s messages as described
in sections 8 and 9 above.
Similar to creating the durable subscribers administratively, the same can be deleted from
the Console, by selecting the Durable Subscribers from the table as shown below.
After selecting any of the durable subscribers from the table, you need to click the
“Delete” button that will display the confirmation page as shown below.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 70 of 87
After successful deletion of the durable subscriber, the following page displays the
remaining list of the durable subscribers as shown below.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 71 of 87
connection.
@exception InvalidSelectorException
The specified JMS selector is
invalid.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 72 of 87
10.3.1 Creating and navigating durable subscribers
The snippet below is used to create a durable subscription named “mydsub1” on the topic
“MyTopic1” using the client id “myclientid1” and how to navigate to one further
management
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 73 of 87
# navigate to the JMSRuntime
cd(‘JMSRuntime/myserver.jms’)
# Method 1.
# get all the durable subscriber runtime MBeans on this topic
# note that this operation would return an array of dsub runtimes
dsubs1=cmo.getDurableSubscribers()
# Method 2.
# get all the durable subscriber runtime MBeans on this topic
# note that this operation would return an array of dsub runtimes
dsubs2=cmo.getJMSDurableSubscriberRuntimes()
To delete the durable subscriber using WLST, you have to first navigate and get hold of
the durable subscriber runtime mbean and pass it as an argument to the delete operation
as shown below.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 74 of 87
# navigate to “MyTopic1” where the durable subscriber will be created
cd (‘Destinations/MyJmsSystemResource!MyTopic1’)
The message management operations on the durable subscriber are same as on the Queue
except that you have to navigate to the durable subscriber runtime mbean before invoking
any message management operation.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 75 of 87
11 Transaction Management
The transaction management allows the users to monitor and manage outcome of the
transactions administratively. The transaction management features spread around both
JMS and JTA subsystems of WebLogic Server. Using these features, you can easily track
and manage all messages associated with the in-flight (pending) transactions and force
the transaction to either commit or rollback.
The transaction management done at JMS subsystem level only affects the JMS branch of
the transaction and do not impact the entire transaction. Although there may be occasions
where you may need to force a commit or roll back of only the JMS branch of the
transaction, it is recommended that you commit or roll back the entire global transaction
using the management features offered at JTA subsystem level to avoid inconsistent
transaction outcome.
To perform the global transaction management, you need to use the JTA runtime
management feature as described in the following sections.
To manage the transaction at the JMS subsystem level, you need to navigate to the
JMSServer monitoring page as shown below. The table lists all the in-flight transactions’
information including it’s the transaction coordinator information, current status and how
long the transaction is in that state.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 76 of 87
Console Screenshot 32. Local Transaction Management on JMSServer Runtime MBean –
Step 1
From this page, you can either force the rollback or commit of the local transaction
branch associated with this JMSServer by selecting the appropriate Xid from the table.
After successful operation, the next page would display the confirmation log message and
the table would list the remaining in-flight transactions as shown below.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 77 of 87
table includes information such as Xid, state and the XA resources that are involved in
that transaction. Note that this page has options for both “local” as well as “global”
transaction management.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 78 of 87
@param xid An Xid in string
representation for a JMS
transaction branch.
@see javax.transaction.xa.Xid
From javax.transaction.Status:
STATUS_ACTIVE = 0;
STATUS_MARKED_ROLLBACK = 1;
STATUS_PREPARED = 2;
STATUS_COMMITTED = 3;
STATUS_ROLLEDBACK = 4;
STATUS_UNKNOWN = 5;
STATUS_NO_TRANSACTION = 6;
STATUS_PREPARING = 7;
STATUS_COMMITTING = 8;
STATUS_ROLLING_BACK = 9;
Returns a set of messages that are
CompositeData[] getMessages(String
associated with a JMS transaction
Xid, Integer timeoutSeconds)
branch. Note that the result set
is returned to the caller in the
form of a message cursor that may
contain messages from several
destinations on this JMS server.
The timeout parameter specifies
the amount of time in seconds for
which the cursor is valid. Upon
timeout expiration the cursor is
invalidated and the associated
resources released.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 79 of 87
processing the request.
@see javax.transaction.xa.Xid
@see JMSMessageCursorRuntimeMBean
Causes the work associated with
forceCommit(String Xid)
the specified transaction branch
to be committed.
The following table lists a set of related JTARutimeMBean APIs that can be used for
global transaction management.
An array of
JTATransaction[]
<code>JTATransaction</code>
getJTATransactions();
objects. Each object provides
detailed information regarding an
active transaction.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 80 of 87
information object for the
getJTATransaction(String xid)
specified Xid. If the transaction
throws RemoteException;
represented by xid does not exist
on the server, then the method
will return null.
@param xid
@return The jTATransaction value
@exception RemoteException
Forces the transaction represented
void forceGlobalRollback(Xid xid)
by xid to be rolled-back at all
throws RemoteException;
participating SubCoordinators. If
the server on which the method is
invoked is not the coordinating
server then the coordinating
server will be notified to process
the rollback.
@param xid
@exception RemoteException
Forces the transaction represented
Void
by xid to be committed at all
forceGlobalCommit(javax.transaction
participating SubCoordinators. If
.xa.Xid xid) throws
the server on which the method is
RemoteException;
invoked is not the coordinating
server then the coordinating
server will be notified to process
the commit.
@param xid
@exception RemoteException
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 81 of 87
# navigate to the root of the server’s Runtime MBean tree
serverRuntime()
# printing the Tx ids obtained in the above step, would result in the
following
#array(['BEA1-0000F45A51A2BD76B51F-
#574C53746F72655F776C5F7365727665725F6578616D706C654A44424353746F7265',
#'BEA1-00005DF81E4ABD76B51F-
#574C53746F72655F776C5F7365727665725F6578616D706C654A44424353746F7265']#
, #java.lang.String)
print txns
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 82 of 87
# print the transaction status
# the output displayed for the command is “0”, which is state ACTIVE
# see transactions API table in section 3 above
print txsts
# Now create a message cursor to hold all the messages that are part
# of the pending transaction id
ptxcursor=cmo.getMessages(ptxns[0],999999)
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 83 of 87
# now call the forceGlobalRollback so the messages will be
# redelivered on both the JMS servers
cmo.forceGlobalRollback(jtaxid)
WLST Snippet 21 – Getting the message info associated with a pending transaction
To get the messages associated with a given transaction, one needs to first get the
transaction id as shown above and use it for creating the message cursor as shown below.
# connect to the server
connect(‘weblogic’,’weblogic’,’t3://localhost:7001’)
# Now create a message cursor to hold all the messages that are part
# of the transaction id (or one can pass in the indexed array element
# like txns[0] instead of the actual tx id for the first parameter
# below) and the cursor timeout value
txcursor=cmo.getMessages(‘BEA1-0000F45A51A2BD76B51F-
574C53746F72655F776C5F7365727665725F6578616D706C654A44424353746F7265’,99
9999)
WLST Snippet 22 – Getting the message info associated with a given transaction
The script below demonstrates how users can administratively “force” the outcome of the
transaction associated with a JMSServer to either “commit” or “rollback” to cause the
message delivery to succeed or to fail.
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 84 of 87
# connect to the server
connect(‘weblogic’,’weblogic’,’t3://localhost:7001’)
12 Conclusion
This paper captures all the related pieces of information regarding WebLogic JMS
runtime message management in a single document. This paper can be used as a quick
reference to understand various aspects of JMS message management and JMS runtime
MBean infrastructure. Finally, this paper demonstrates how WLST can be used as a
command line administration tool to manage JMS messages at runtime.
13 Errata
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 85 of 87
Performing “move” operation of the UOO messages can cause problems regardless of
whether any UOO messages remain in the original destination or not. After the move is
performed, any new UOO messages produced for the same UOO, could still load-balance
to the original destination - which effectively splits the UOO and its ordering. For path
service based routing of UOO, the path service does not know about the move, or at most
may figure out that the old destination doesn't own the UOO (but not where the UOO
was moved). Hash based routing will always send new messages for the UOO to the
same place. Both of these cases may potentially lead to corrupted UOOs.
14 Appendix A - References
________________________________________________________________________
WebLogic JMS Runtime Message Management in a Nutshell Page 86 of 87
1
http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/
2
http://e-docs.bea.com/wls/docs103/wlsmbeanref/core/index.html
3
http://e-docs.bea.com/wls/docs103/javadocs/weblogic/jms/extensions/package-summary.html
4
http://java.sun.com/j2se/1.5.0/docs/api/javax/management/openmbean/package-summary.html
5
http://e-docs.bea.com/wls/docs103/config_scripting/using_WLST.html
6
http://www.jython.org.
7
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jms/uoo.html