Shelby's Blog
How to use MQ JMSJCA to connect to IBM WebSphere Message Queue 6.0 in 5.1.3 Java CAPS
Instructions on how to use MQ JMSJCA to connect to IBM WebSphere Message Queue 6.0 in 5.1.3 Java CAPS
In the Environment->WebSphereMQ->Configuration
1) Use the "IBM MQ Message Server URL" field to specify a host name and a port number. For example:
wmq://localhost:1414
Content of the "QueueManager" field will be appended to the "IBM MQ Message Server URL field" to form a complete URL
wmq://[hostname]:[port]?QueueManager=[queue manager name]&option1=value1&option2=value2
2) Use the "QueueManager" field to specify the name of a queue manager. For example:
QM_myQMgr
3) If you want to add options to the URL, you have to add them to the "QueueManager" field. For example to turn off XA and to switch to the "binding" mode, type the following in the "QueueManager" field:
QM_myQMgr&JMSJCA.NoXA=true&TransportType=JMSC.MQJMS_TP_BINDINGS_MQ
In the above you need to replace QM_myQMgr with the name of a real queue manager. And for the rest, you need to type exactly as shown. Options are separated by the "&" character which is "&" in HTML. The following options are supported:
TransportType
Channel
JMSJCA.NoXA
The default transport type is "client" TCP, if you do not have
TransportType=JMSC.MQJMS_TP_BINDINGS_MQ
option in the "QueueManager" field.
The default transaction mode is XA if you do not have the
JMSJCA.NoXA=true
option in the "QueueManager" field.
3) The "TransportType" field in the GUI is ignored due to a defact. It does not matter what
you enter here. You have to use the "QueueManager" field to switch to the "binding" mode.
4) Before deploying your project, copy the following jar files to
* com.ibm.mqjms.jar
* com.ibm.mq.jar
* com.ibm.mqetclient.jar
* dhbcore.jar
com.ibm.mqetclient.jar is not needed for "binding" mode.
5) MQ JMS supports JMS API. You can use it just like a normal JMS server. However you have to use tools provided by IBM (e.g., MQ Explorer) to monitor the MQ. Enterprise Manager management functionality is not supported for WebSphere MQ. Only JMQ, Grid and STCMS are supported.
Posted at 01:27PM Jan 24, 2008 by Shelby in Sun | Comments[1]
Using MQSeries eWay in Java Composite Application Platform Suite
1) For WebSpher MQ eWay inbound receive mode you can increase or decrease the message retrieving interval in the "Connectivity Map." Click the eWay connection in "Connectivity Map," the "Inbound eWay Configuration" window now opens. In the "Inbound eWay Settings," change the "Schedule Interval" to a value you want (the default is 5000 milliseconds). However because of a limitation in IBM MQ API, a single connection to an MQ queue manager cannot support multiple threads, therefore, in the eWay implementation, a lock is used to control the access to an MQ connection. Only one thread can access the connection at a time. This basically serializes the MQ eWay inbound. Because of this limitation, it is suggested that you set the "Schedule Interval" to zero and create multiple instances (routes) of the same JCD and point them to the inbound MQ eWay. The reason for this is that when "Schedule Interval" is non-zero, multi-threads are used to retrieve messages from one MQ connection for one JCD instance in the Connectivity Map, but the threads are serialized by the lock. Whereas when "Schedule Interval" is zero, a single thread is used to retrieve messages from one MQ connection for one JCD instance, but since you have created multiple instances of the JCD and each instance uses its own connection, you have made it multi-threaded. This of course defeats the J2EE container controlled connection pooling and thread management because the user now controls the number of MQ inbound connections and the number of instances of the JCD. You also need to set MQGMO_WAIT to "True", and "waitinterval" to 1000 (or a value you are comfortable with) as well to prevent the JCD thread from spinning when there is no message which can happen when "Schedule Interval" is zero.
2) MQ receive() does not support XA. To use XA you have to use MQ eWay's outbound mode, where you will call receive() explicitly inside your JCD. You need to find a way to trigger the JCD. Use a Scheduler if you can tolerate the minimum 1 second triggering interval. Or use a dummy SeeBeyond JMS queue filled with triggering messages if you want a faster turnaround. For XA it is recommend to forgo the MQ eWay and use the JCA compliant, MQ JMSJCA instead.
3) The default mode for MQ receive() is the "destructive get", meaning once a message is retrieved from a queue, the message is remove permanently, no commit is needed. You may lose messages if sending message to an outbound destination fails. To allow commit and rollback, you need to use the "sync point." (See 4) for more details on sync point.)
Message may also appear to be lost in default mode (without sync point) if a lingering eWay message receiving thread fails to undeploy and messages on the queue can be consumed by this thread. If you see input connections on the IBM MQ Explorer not being zero after you have undeployed your project, you have got a lingering receiving thread which will consume messages without your knowledge. Shut down the IS is the only sure way to prevent this from happening.
4) To use the "sync point," you need to set the "Schedule Interval" to zero. The reason for this is that when "Schedule Interval" is non-zero, multi-threads are used to retrieve messages and the "sync point" does not work well with multi-thread. When "Schedule Interval" is zero, a single thread is used. You may lose messages if you don't set the "Schedule Interval" to zero when using "sync point." In "Inbound eWay Settings" > "GetMessageOptions" > "options," set "MQGMO_SYNCPOINT" to "True", MQGMO_WAIT to "True", and "waitinterval" to 1000, the latter two settings prevent the thread from spinning when there is no message. You can create multiple routes in Connectivity Map to make it multi-threaded, i.e., by creating multiple instances of the same JCD.
With "sync point" enabled, you need to call commit explicitly inside your JCD, e.g.,
input.getSyncpointController().commit();
or backout if there is an error
input.getSyncpointController().backout();
Posted at 09:18AM Jan 24, 2008 by Shelby in Sun | Comments[1]