Outbound MQS WebSphere interface

I figured I’d update this in case anyone else stumbles across this in the future.  Evidently I needed one of the “Put Msg Options” to be “MQPMO_SYNCPOINT”.  This doesn’t make sense to me as IBM’s definition of this setting is as follows:

The request is to operate within the normal unit-of-work protocols. The message is not visible outside the unit of work until the unit of work is committed. If the unit of work is backed out, the message is deleted.

You would think that would mean it would error on the side of letting an application pick it up before it was done writing it.  But it works like a champ when I have that attribute set so I’ll go with it.

I’m doing some volume testing, but currently I have the commit interval at ‘1’.  I would like to keep that setting unless I find issues as the Cloverleaf documentation warns about an issue that can occur between the time the message is read and commited that could make the message(s) be sent multiple times.  I’m thinking that a lower commit interval would minimize the number of duplicates sent if there’s an issue.  (I could keep track of the msg ID’s in SQL light and check every one but this is a result interface so that would be overkill.  If it were a charge interface I’d consider it.)

I’m assuming that MQPMO_NO_SYNCPOINT was what it was set to when I left it blank.  IBM’s documentation says that if you leave it blank than it defaults to one or the other.  I’m suspecting that if I use “NO_SYNCPOINT” that I will get the initial behavior that I observed.  I’ll try it and will update this thread if the results are other than expected.

I was wrong.  If I set the “Put Msg Options” to “MQPMO_NO_SYNCPOINT” the interface seems to function correctly as well.  I guess it’s just a problem with leaving it blank.  I’ll probably stick with “MQPMO_SYCPOINT” as I would like it to finish commiting the messages before they are visible in the queue.

Do you have experience with MQ interfaces Peter?

Do you have any sugestions or things to consider when choosing a commit interval, Read interval, max messages, etc?

So far it appears there is little to no latency in the transfer of messages to/from queues.  If I set my read interval to 2 seconds and my max read to 100 messages and my commit interval to 1 it can pull 500 messages off the queue in 15 seconds.  That’s including the regsub command I have to strip the MQ header off.

Thanks for your input on this.  It kind of shows me I’m on the right track.  I have been able to dump 500 messages into a queue in 8 seconds and read all 500 of them from a queue within 8 seconds too.  However, I have to choose a read interval of at least 1 and if I set my max read messages to 1 as well that means I’m capped out at 1 message per second which may not be good enough.  I’ll have to check the traffic on that interface.

Thanks again! Any other advice you have is very appreciated!