| Author |
Message
|
| Sam King |
 Posted: Thu Feb 17, 2011 8:24 am Post subject: Strange problem reading nonJMS mesages in XMS .Net |
 |
|
Newbie
Joined: 17 Feb 2011
Posts: 7
|
I have been using XMS.net for sometime, primarily for sending JMS style messages. I am now developing a prototype that uses XMS .net to send and receive non JMS style (native MQ) messages.
Here is the scenario:
I first send a non JMS style message to a queue (MQ 7) using XMS .Net. I set the WMQ_TARGET_CLIENT property to WMQ_TARGET_DEST_MQ on the destination queue object to indicate a non JMS destination. My program ends and I can see the message in the queue.
Then at a different point in time, I create a message consumer( using XMS .Net and again setting WMQ_TARGET_CLIENT property to WMQ_TARGET_DEST_MQ ), to GET the same non JMS message created above. The message gets picked up by my code( I can see the body of my message if I set a break point).
But when my program ends, the message is still in the queue and the message count increases by one. It is as if the GET is not getting commited to MQ or some kind of roll back is happening. I even call the message consumer's close method before my program ends.
What am I doing wrong?
The same XMS code used in the above scenario works fine if I send a JMS style message and GET that JMS style message( i.e if I do [b]not[/b] set WMQ_TARGET_CLIENT property to WMQ_TARGET_DEST_MQ ). In this case the the message is completely removed from the queue.
Also, instead of the above XMS code, if I use the WebSphere MQ classes for .net lib (amqmdnet.dll). I am able to GET the above non-jms message. It gets completely removed from the queue.
I am using MQ 7 and IA9h 2.0.0.3 for XMS.
Thanks in advance for your suggestions. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Feb 17, 2011 8:47 am Post subject: Re: Strange problem reading nonJMS mesages in XMS .Net |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam King wrote: |
| I am using MQ 7 and IA9h 2.0.0.3 for XMS. |
Which v7? The page for that support pac stipulates v7.0.1.0 (and v7.0.1.3 is a good idea for all the usual reasons).
I also thought v7 had XMS support built in. Am I wrong? If not, what does the support pac provide that the base support does not? Anyone?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Sam King |
| Posted: Thu Feb 17, 2011 9:04 am Post subject: |
|
|
Newbie
Joined: 17 Feb 2011
Posts: 7
|
Thanks Vitor.
The MQ server version is 7.0.1.3
My .net program is being run on a different machine than the MQ server. So I have installed the XMS on the machine from which the .Net program is running. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 17, 2011 9:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You seem to have identified the issue properly as a question of transactionality.
Whether or not changing the WMQ_TARGET_CLIENT property will have any affect on the transactionality of the session, I don't know off hte top of my head.
But it's worth reviewing the documentation to find out, and then making sure that you are taking steps to ensure the right level of transactionality for your program. |
|
| Back to top |
|
|
| Sam King |
| Posted: Thu Feb 17, 2011 3:55 pm Post subject: |
|
|
Newbie
Joined: 17 Feb 2011
Posts: 7
|
Okay.
I figured out what is happening. The problem has to do with the DELIVERY_MODE of the message and the acknowledgement mode of the session
The problem occurs while receiving the message if, the destination's WMQ_TARGET_CLIENT property is set to WMQ_TARGET_DEST_MQ and the message to be received is a PERSISTENT message . In this case the session seems not to acknowledge the receipt of the message if the session's acknowledgement mode is AutoAcknowledge. Now, if I set the acknowledgement mode of the seesion to ClientAcknowledge and explictly acknowledge the receipt of the message by calling the acknowledge method of the message, the message gets properly removed from the queue.
If WMQ_TARGET_CLIENT is set to WMQ_TARGET_DEST_MQ and the message to be received is a Non_Persistent message, this message is properly received(removed from the queue) even if the sessions acknowledgement mode is set to AutoAcknowledge. This means that the session is successful in acknowledging the receipt of message in this case.
Now the question is: is this a bug? Or are my findings incorrect, this problem cannot be reproduced and the problem lies somewhere else?
I prefer AutoAcknowledge and want to receive non jms persistent messages. How do I do it?
Thanks |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 17, 2011 8:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Sam King wrote: |
I prefer AutoAcknowledge and want to receive non jms persistent messages. How do I do it?
Thanks |
You might also want to check what behavior is set on the transactional mode of the qcf/tcf and of the session. Typically I do all the gets / receives within a transacted session. The session.commit() will then handle the acknowledgments correctly.
Also I would go to V7.0.1.4 and remove the fixpack. Use the XMS client delivered with the product. There have been quite some fixes in the JMS and XMS area between 7.0.1.3 and 7.0.1.4
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Sam King |
| Posted: Fri Feb 18, 2011 3:07 pm Post subject: |
|
|
Newbie
Joined: 17 Feb 2011
Posts: 7
|
Thank you fjp_saper.
If my session is transacted, the commit acknowledges the message properly, as you mentioned in your reply.
So the question still remains:
Why AutoAcknowledge does not work for receiving a nonJMS persitent message in a non transacted session?
Thanks |
|
| Back to top |
|
|
| Sam King |
| Posted: Fri Feb 18, 2011 3:08 pm Post subject: |
|
|
Newbie
Joined: 17 Feb 2011
Posts: 7
|
My bad. Sorry I mistyped your name fjb_saper  |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Feb 18, 2011 3:50 pm Post subject: Re: Strange problem reading nonJMS mesages in XMS .Net |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Sam King wrote: |
| What am I doing wrong? |
Maybe nothing.. there have been bugs in XMS.net, and it might be best to install the latest (a quick check shows they are at 2.0.0.4, and check out the list of APARs, it looks like some could be relevant).
By the way, XMS is supposed to help you work with MQ's JMS messages. Is it really a good plan to start using it for non-JMS? (I don't even know if that's possible, I must admit)
There are some really mature APIs with MQ, and also a .net interface I think. These might be more appropriate if you want to use non-JMS MQ messages.
As always, if you think there is a defect, you could try to open a PMR. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 18, 2011 7:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Sam King wrote: |
Thank you fjp_saper.
If my session is transacted, the commit acknowledges the message properly, as you mentioned in your reply.
So the question still remains:
Why AutoAcknowledge does not work for receiving a nonJMS persitent message in a non transacted session?
Thanks |
Don't remember where I read it (best practices?) but apparently there is a performance penalty attached to doing receives outside of a transacted session, or gets outside of syncpoint, if you are multi-threaded and have more than one instance of the consumer running.
So I would suggest to you a 2 pronged approach
- open a PMR and get clarification of the behavior and possibly a fix
- in the meantime have your session transacted...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| shashikanth_in |
| Posted: Sat Feb 19, 2011 10:35 pm Post subject: |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
Your problem looks similar to IZ87162. Google gives the link for this APAR but can't open it. Comment says "Persistent messages are consumed but not acknowledged so when closing the application, persistent messages are put back on".
Looks like this APAR has been included in the latest XMS .NET fixpack. So download the latest fixpack and try. |
|
| Back to top |
|
|
|
|
