List of all the constants
WebSphere MQ Posts
All Blog Posts
List of all the constants
MQ (String Lengths)
MQ (Command format String Lengths)
MQRC_* (Reason Codes)<td class="entry" valign="top"
[Edited By Moderator]
IBM Announcement: End of Support for WebSphere MQ V6 - Middleware NewsOn September 30 2012, IBM will withdraw support for WebSphere MQ v6.0 under the International Program License Agreement (IPLA). The replacement product is WebSphere MQ for Multiplatforms V7.x.
Support will be withdrawn for all Websphere MQ components including Server, Client and MQ Explorer of following platforms :
Processing messages with the WebSphere Application Server V7 and V8 WebSphere MQ messaging provider activation specifications
IBM® WebSphere® Application Server V7 and V8 provide support for asynchronous messaging based on the Java Message Service (JMS) specification. Using the WebSphere MQ messaging provider, you can write message-driven beans that listen on a WebSphere MQ destination (either a message queue or a topic). When a message arrives on the destination, the message-driven bean's onMessage() method is invoked to process the message.
In WebSphere Application Server V7 and V8, the WebSphere MQ messaging provider supports the use of activation specifications to monitor destinations hosted by WebSphere MQ queue managers. This article shows how activation specifications connect to WebSphere MQ on distributed platforms, describes the mechanism used to monitor the destinations looking for messages, and then shows how message-driven beans are invoked after a suitable message has been detected. The article assumes a basic knowledge of JMS and WebSphere MQ.
In general terms, J2C activation specifications are administered objects that contain information about how to connect to a JMS provider, along with details of the destination on that JMS provider that will be monitored for messages. When deploying an application that contains a message-driven bean, you need to specify the activation specification that the message-driven beans will use. When the activation specification starts up, it connects to a JMS provider, opens the JMS destination, and then monitors it looking for messages.
Figures 1 and 2 below show a sample WebSphere MQ activation specification that has been defined using the activation specification panel in the WebSphere Application Server Integrated Solutions Console. When this activation specification starts up, it makes a BINDINGS mode connection to a local WebSphere MQ queue manager called pault, opens the destination jms/TestQueue, and then starts monitoring this destination for messages.
Figure 1. Specifying the queue manager name and transport type
Figure 2. Specifying the JMS destination that an activation specification will monitor
Activation specifications can be configured to use message selectors, which enables them to only pass messages that meet the selection criteria to message-driven beans. In Figure 2 above, no message selector has been specified, and therefore all messages that arrive on the destination are suitable for processing by this activation specification.
Once an activation specification finds a suitable message, it schedules a piece of work within the application server to process it. Each message requires a JMS server session in order to run, and multiple messages can be processed at the same time.
Each activation specification has an associated server session pool, and its size controls the number of messages that can be processed concurrently by an activation specification. The default size of the server session pool is 10, which means that up to 10 messages can be processed at the same time by a single activation specification. To change the server session pool size, modify the activation specification advanced property Maximum server sessions, as shown in Figure 3:
Figure 3. Specifying how many messages can be processed concurrently
The mechanism that an activation specification uses to detect messages on JMS destinations hosted on a WebSphere MQ queue manager varies depending on the WebSphere MQ messaging provider mode that is being used, as described below.
Activation specifications use the WebSphere MQ messaging provider normal mode if they are connecting to a WebSphere MQ V7 queue manager and they have the Provider versionproperty set to either unspecified (the default value) or 7. In this mode of operation, the activation specification takes advantage of a number of the features of WebSphere MQ V7 when connecting to a queue manager and getting messages. When it starts up, the activation specification:
Now, when a suitable message arrives on the queue that the activation specification is monitoring, or is published on the topic that the activation specification has subscribed to, the queue manager marks the message to prevent any other activation specifications from seeing it, and then passes details of the message to the activation specification via the callback that was set up earlier.
The other way that activation specifications can connect to a WebSphere MQ queue manager is by using the WebSphere MQ messaging provider migration mode. This mode is used if one of the following conditions is true:
When the activation specification starts up in migration mode, it:
When an activation specification has detected a message on a destination (either because a WebSphere MQ V7 queue manager has passed back information about a message via a callback, or because the activation specification has browsed a suitable message), it:
The activation specification then goes back to looking for more messages.
As mentioned earlier, activation specifications will process up to 10 messages concurrently by default. What happens if an activation specification tries to process a message and all 10 server sessions are already busy processing messages? In this situation, the activation specification will block until a server session becomes free. As soon as a server session is available, the activation specification loads it up with the message reference, and then schedules a new piece of work so the server session can run again.
Once the activation specification loads a server session with a message reference, it schedules some work so that the message can be processed. What happens to the work? The Work Manager:
After the work has been scheduled, the application server Work Manager will run this piece of work at some point in the future. The work, when started:
To improve performance, the connection to the queue manager that the server session uses is left open after the message has been processed and the work completed. Then, the next time the server session is used to process a message, it need not reconnect to WebSphere MQ and reopen the queue containing the message. By default, unused server sessions associated with activation specifications are left open for 30 minutes before being closed off. You can later this timeout period by modifying the value of the activation specification advanced property Server session pool timeout, as shown in Figure 4 below
On a lightly loaded system, the time between the piece of work being scheduled and the Work Manager starting the work can be just a few milliseconds. On busy systems, there may be a lengthy delay before the work is actually started. There are two possible reasons for a delay:
The Work Manager records when a piece of work was scheduled, and when it starts the work, it checks how much time has elapsed since the activation specification scheduled the work. By default, the activation specification expects the work to be started within 10 seconds of it being scheduled. If more than 10 seconds elapse before the Work Manager starts the work, then a WorkRejected exception is returned back to the activation specification, causing exceptions similar to the one below to appear in the application server SystemErr.log:
When an exception like this one occurs, the message in the Message Reference will have been "unmarked" by the queue manager, so that it can be reprocessed. You can change this 10-second time limit on the activation specification Advanced properties panel using Start timeout, as shown in Figure 4:
Figure 4. Modifying the server session timeout and the amount of time to wait for work to start
Earlier, it was mentioned that a piece of work might get delayed if there are not enough threads in the WMQJCAResourceAdapter thread pool, which leads to the obvious question, "What should the size of this thread pool be?". One thread pool per application server is used by activation specifications to run server sessions. Each activation specification has an advanced property called Maximum server sessions, which defines the maximum number of concurrent server sessions that can be running at the same time. Since each server session is used to process messages, this property essentially says how many messages can be processed concurrently by message-driven beans using this activation specification. So in order to determine what the size of the WMQJCAResourceAdapter thread pool should be, you need to add up the values of the Maximum server sessions properties for each WebSphere MQ messaging provider activation specification on the application server. For example, suppose you have 25 activation specifications defined, each with the Maximum server sessions property set to 3. In this situation, there can be up to 75 server sessions running concurrently, each of them using a thread from the WMQJCAResourceAdapter thread pool. Therefore you should set the maximum size of this thread pool to 75. Figure 5 shows the WMQJCAResourceAdapter thread pool panel in the WebSphere Integrated Solutions Console, where you can change the size of this thread pool:
Figure 5. Changing max number of threads available to all activation specifications defined in the application server.
If you start seeing WorkRejected errors appearing in the application server SystemOut.log file, the first thing to check is that the WMQJCAResourceAdapter thread pool is large enough to handle all of the server sessions needed by your activation specifications. If the thread pool is the right size, then the errors are caused by the Work Manager being unable to start the work request within the specified time period. In this situation, you should either increase the value of the activation specification advanced property Start Timeout, or investigate reducing the load on your application server system.
As described above, there are three situations in which there might be a delay in between a message being detected and that message being processed by a message-driven bean:
If the activation specification is running in WebSphere MQ messaging provider normal mode, the queue manager marks messages before passing their details back to the activation specification. Marking the message means that no other activation specification (or WebSphere Application Server Listener Port), either running in the same application server or on a different application server, can see the message, which prevents another message-driven bean from getting the message before a server session has had time to process it.
By default, messages are marked for 5 seconds. To change this time period, modify the WebSphere MQ queue manager property Message mark browse interval (MARKINT).
After WebSphere MQ has passed details of a message to process to an activation specification, the 5 second timer starts. During these five seconds:
If there is a delay in getting a server session or a thread from the WMQJCAResourceAdapter thread pool, or if the system is busy and it takes a long time for the Work Manager to schedule the work, then the time between WebSphere MQ passing details of the message and it actually being consumed might be longer than 5 seconds. What happens in this situation?
Well, if the message has been on the queue for longer than 5 seconds, the queue manager will unmark it, and another activation specification or listener port is then free to come along and get the message. If this happens, then when the server session that has previously been given details of this message tries to get it, it will find that the message is no longer on the destination, and write the following message to the application server SystemOut.log:
Should you see this message, you have three options:
This article described the mechanisms that activation specifications use to get messages from WebSphere MQ queue managers, including how activation specifications create a connection to a queue manager and the mechanisms they use to monitor JMS destinations looking for suitable messages to process. The article also described how the application server schedules the processing of messages, once a suitable message has been found.
[Edited By Moderator]
Page 10 of 18 • Prev 1 ... 8 9 10 11 12 ... 18 Next