T.Rob Wyatt

Hi,

Using IBM MQ when I publish a message and then get it with a subscriber, the JMSMessageID returned from the publish and the subscribe are different. I would have expected them to be the same because otherwise how could Request/Reply work? I posted to Stack Overflow and Nigel Deakin the JMS Spec Lead confirmed that the intent is that the subscriber(s) should see the same JMSMessageID as the publisher got back from the send. IBM replied that the spec supports their interpretation in which the JMSMessageID changes, but they will consider requests to change the behavior.

See: http://stackoverflow.com/questions/29001655/should-the-jmsmessageid-change-between-publish-and-subscribe

With that in mind, I was wondering...

What behavior would *you* expect in this situation? Would you be surprised if your transport provider changed the JMSMessageID across a Publish API call?

What behavior do other transport providers exhibit? If you log the JMSMessageID as seen by a publisher and a subscriber in [Tibco | ActiveMQ | RabbitMQ | WAS | ...] do you get the same value?

I need to provide use cases to justify my enhancement request. Is this a feature you rely on using some other transport? If yes, what kind of use cases do you have?

I'm pretty sure I will be able to get IBM to make the change with what I have so far but some of these questions potentially upgrade the ammunition I have to use. It isn't often you get to club IBM over the head with their own mistake and force them to change so if you want to be a big part in a very tiny piece of history, please respond.

Thanks!
-- T.Rob

Go to http://ibm.co/SupptPacMQC71 and download the WMQ client. Make sure to install the sample code. There are both Java and JMS samples, as well as XMS, .NET, C# and C. Then take a look at the Infocenter Java or JMS sections, depending on what it is you are using.

nitss bhavsar wrote:hello, I have to send the message to websphere MQ through servlet(webpage that will put the message into the queue and read the message from queue.).
I m new to servlet .so i need help to complete this assignment.please if possible post the servlet code here that will use JMS to put and read messages from websphere MQ,I m using Websphere 6. here..
thanks in advance,

It would be helpful if you could say which of the IBM code samples you looked at and what about your requirement the samples failed to address. Also, when you mentioned WebSphere 6 you were referring to the app server version, right? Which version of WebSphere MQ client and server are you using?

You should be able to specify a transacted session and get 1-phase commit. Just use the COMMIT verb after each set of messages. Since you aren't using transactions now I'll assume that you don't need 2-phase commit but if you did you'd need to use an XAConnectionFactory instead of a ConnectionFactory. If you needed 2-phase commits the app server configuration would impact your app. With 1-phase commit there are some app server settings that would provide transaction management in the container but in this case it's probably easiest to just specify a transacted session and issue COMMITs. Just remember that the scope of the transaction is the session. So if you have multiple threads, each must have its own session or else they will COMMIT against each other's work which is probably not what you want.

Syed Mahdi wrote:...if there are two nodes in a cluster and both have my MQ adapter to access the MQ and one goes down half way thru the communication how can i transfer that state to the other node telling it to complete the half done communication. Does websphere has any feature to register what is happening on the MQ level.

Transactional sessions. When the first node goes down the transaction will roll back so that instead of a "half done communication" that unit of work reverts back to an "unstarted communication."

Since you specified that WMQ clustering is not used then there is only one instance of the queue. When multiple application instances are reading off the same queue, they are all competing for the same messages. If one application fails, the other instances will continue to consume off the queue and receive messages that the first instance would have received. If one application puts a message, commits it and then attempts to read it back, it is entirely possible that another application will already have read it before the first can get it, if they are reading in FIFO order. Of course, if they are reading by MsgID or CorrelID then the other app instance would somehow have to be passed the ID in order to select that specific message.

Yes and no.

JMS is just a specification underneath which you need a transport provider. WMQ is one of many implementations of a JMS transport and in that sense it offers exactly the same functionality as s simple JMS queue (or topic).

But at the same time, WebSphere MQ offers considerable functionality that is not specific to JMS. For example, WebSphere MQ has the concept of a "retained publication." This functionality retained the last message to be published on a given topic so that newly subscribed applications do not need to wait for subsequent publications. There are many other examples of how WMQ provides a superset of JMS functionality but I don't want to stray too far off topic for this forum.

But the short answer is that yes, WMQ does offer different functionality than a simple JMS queue should you choose to use it. If you need some of the WMQ-native functionality and this does not violate a business requirement regarding JMS compatibility then by all means use it. If your requirement is for a JMS-compliant transport make sure to stick with the JMS API and functionality in which case you can treat WMQ as if it were a simple JMS queue.

T.Rob Wyatt wrote:Note that the Ben Ritchie article that was linked provides instructions on how to configure JBoss to talk to a LOCALLY INSTALLED QMgr using XA. Since you are not connecting to a local WMQ server using shared memory connection as described in the article but instead are using a remote network connection, the article does not directly apply to your configuration. You won't be able to use bindings mode connections and therefore will not get XA functionality.

Sorry, I needed to read Ben's article further. He *does* show you how to configure the Extended Transactional Client but the instructions assume you have a fully licensed WMQ Server installed locally. This is probably where the disconnect lies here. In the article Ben starts by assuming that WMQ Server is installed and then has you copy mqetclient.jar (the extended transactional client) to the server lib directory. What isn't mentioned in the article is that use of mqetclient.jar (the Extended Transactional Client) incurs a full WMQ license obligation on the client host server in addition to any license on the WMQ QMgr server. Because the article assumes a fully licensed WMQ install has been performed, it is correct to simply copy this jar file from the install directory to install_path/server/default/lib on the same host. Also because the article starts with a WMQ Server already locally installed, Ben doesn't walk you through obtaining the WMQ client and installing it.

Sooooo...to follow the article and stay in full compliance you'd want a licensed WMQ server install on the JBoss host and then just use the XA client components of it. If all you want is client and don't need XA then download the installs I've linked above.

Azrael Noor wrote:

However, since the WMQ client install includes a lot of functionality not delivered in the jar files, and since the full install is the only supported configuration, I haven't given up on trying to convince you guys to try it.

So Sir you mean
first, i should purchase IBM Websphere MQ or freely download it from some torrent,
have a full install it on system
and then copy require rar's and use the IVT or Diagnostic Trace to solve problems?
am i getting right

No, I'm saying that you can download the FREE WMQ client from the links provided and install that on your JBoss server. Those links again are:

FREE WMQ V7 client: http://bit.ly/SupportPacMQC7
FREE WMQ V6 client: http://bit.ly/SupportPacMQC6

Note that the Ben Ritchie article that was linked provides instructions on how to configure JBoss to talk to a LOCALLY INSTALLED QMgr using XA. Since you are not connecting to a local WMQ server using shared memory connection as described in the article but instead are using a remote network connection, the article does not directly apply to your configuration. You won't be able to use bindings mode connections and therefore will not get XA functionality.

Azrael Noor wrote:Jaikiran Pai and Rob Wyatt
...
What settings i have to do at jboss v4.0.3SP1 to recieve message from server(contains websphere mq to send messages)
...
you mean to say i should call IBM for settings of jboss??

I don't know the JBoss settings, hopefully someone else here will help with that. I'm just suggesting to start with a correctly installed version of WMQ client. My experience from working many PMRs for many clients is that a ticket gets opened with something like "my WMQ JMS client isn't working." Then when we start digging in and the IBM tech says "well take a trace" or "run this diagnostic command" the reply comes back that these are not available because instead of a full install, someone copied the jar files over and tried to cobble it together themselves. At that point the IBM support person says "well if you want support you need to install the full client so we can run these diagnostics." As soon as the client is installed, the environment variables set as per the docs and the Initial Verification Test programs successfully, run, the application problem magically disappears. Of course, this does not fix the problem in every case but in about half the cases I've personally worked simply installing the WMQ client as per the vendor specs resolves the problem. I *always* start there.

And, no, I'm not suggesting calling IBM for JBoss settings. But if you have the full client install you can use the verification test programs to connect to the QMgr and verify your install and if those fail, you can and should call IBM for support. Once the IVT programs work, then and only then should you move on to getting JBoss running with WMQ except now it will be with a known working install instead of guesswork.

For what it's worth. I realize the culture of the JMS crowd is based on "just give me the jar files" and resistant to the notion of using vendor-provided install procedures such as these. Especially those that require root. However, since the WMQ client install includes a lot of functionality not delivered in the jar files, and since the full install is the only supported configuration, I haven't given up on trying to convince you guys to try it.

Is this a toy application or just for your own study? Because if it is going to be a real application that your business depends on then you should be aware that support from IBM requires that you actually install the full WMQ client. In addition to the WMQ Jar files, this installs utilities such as the ability to tun traces, display the version you have installed, the install verification test utilities and apply maintenance. Frankly, even if it is a toy application one wonders why anyone would attempt to get something working by guesswork rather than just run the vendor-supplied install. Also, if you run the IBM installer instead of grabbing the jar files from the V6 server you can use the V7 client. If you build the app on V7 client and run against V6 server it is compatible but it saves you from having to upgrade the client later (WMQ V6 is end of life as of Sept 2012).

Download the V7 client at http://bit.ly/SupportPacMQC7
Download the V6 client at http://bit.ly/SupportPacMQC6

WMQ V7 Using Java Manual
WMQ V6 Using Java Manual

It sounds like you have a poison message. WMQ will requeue a poison message if possible. When this happens, the poison message is removed under syncpoint from the input queue and written under syncpoint to the backout or dead queue. It is not committed until another message in the input queue *is* able to be committed. If there is no subsequent message in the input queue, the poison message transaction never completes. Then every so often, the transaction times out, the message PUT and GET are backed out and the cycle starts again.

If my theory is correct you can put another message - a GOOD one this time - on the input queue and the transaction will complete. Or you can stop the app and when there are no input handles on the queue, the poison message should be the only message on the queue and you can delete it.