| Author |
Message
|
| 70033 |
 Posted: Mon Dec 22, 2008 10:33 am Post subject: MQ as a jms provider(MQSTR versus MQRFH2) |
 |
|
Apprentice
Joined: 22 Dec 2008
Posts: 27
|
Following is my client set up javascript:emoticon(' ')
1. Dot net MQ client pumping messages onto their remote queue(which comes to our local queue) with MQSTR as the format
2. they send xml data (which probably doesnt matter for the problem that i am having ) in a string format
Following is my server set up javascript:emoticon('')
1. WAS 6.0(Websphere application server 6.0) with MQ as the jms provider .
WAS details: 6.0.2.25
Build Number: cf250801.02
Build Date: 1/8/08
WMQ details : Version: 6.0
2. Recently we migrated from WMQ 5.3 to WMQ 6.
3. I have listeners listening on a jndi which is configured to listen to a MQ in WAS and these listeners are configured in the MDB.
4. The server(the MDBS) then uses the replyTo from the message and then do a jndi lookup on that and then send a jms reply . the jndi lookup will internally give it a handle to the MQ .
Following is my problem.javascript:emoticon(' ')
1. When I drop the message from my java client(to simulate the dotnet clients push very closely) using MQRFH2 the replyto in the MDB that i am listening to has the right format
queue:///<<Queue Manager>>/<<Local Queue>>
2. However when i drop the message from my client using MQSTR which incidentally i did with the following lines of code
Queue queue = (Queue)context.lookup(replyToQueueName);
System.out.println("Setting the target to be non jms");
((MQQueue)queue).setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ);
QueueSender sender = session.createSender(queue);
then i get the following as the replyTo in the MDB (The MDB is configured with the help of a listener to a Queue in Websphere MQ)
queue:///<<Queue Manager>>/<<Local Queue>>?targetClient=1
I dont understand javascript:emoticon('') why i am getting ?targetClient=1 added to the replyTo queue specified in the request.
Within the mdb we do a jndi lookup to post a jms reply and we fail with the
CosNamingException (Because it is trying to lookup everything including the targetClient=1 and it doesnt find it).javascript:emoticon(' ')
Is there any configuration that i need to do anywhere (in WAS or in WMQ) to fix this problem ?
I would like to add that this used to work when we had MQ 5.3 and both the client and the was configuration has not changed. I did the following
1. Changed the target to be MQ instead of JMS in the websphere but it didnt help. I still got the same CosNaming when doing a jndi lookup
2. Tried the same in my other instance with WAS 6 and WMQ 5.3 and that worked with both MQSTR and MQRFH2.javascript:emoticon(' ')
I have the following questions?
1. How do i suppress the "targetClient" in the replyTo?
2. Why is Websphere adding it and why is it going away when doing with MQRFH2 .
Please
 |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Dec 22, 2008 2:23 pm Post subject: Re: MQ as a jms provider(MQSTR versus MQRFH2) |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| 70033 wrote: |
Following is my server set up javascript:emoticon('')
1. WAS 6.0(Websphere application server 6.0) with MQ as the jms provider .
WAS details: 6.0.2.25
Build Number: cf250801.02
Build Date: 1/8/08
WMQ details : Version: 6.0
2. Recently we migrated from WMQ 5.3 to WMQ 6.
3. I have listeners listening on a jndi which is configured to listen to a MQ in WAS and these listeners are configured in the MDB.
4. The server(the MDBS) then uses the replyTo from the message and then do a jndi lookup on that and then send a jms reply . the jndi lookup will internally give it a handle to the MQ .
Following is my problem.javascript:emoticon('')
1. When I drop the message from my java client(to simulate the dotnet clients push very closely) using MQRFH2 the replyto in the MDB that i am listening to has the right format
queue:///<<Queue Manager>>/<<Local Queue>>
2. However when i drop the message from my client using MQSTR which incidentally i did with the following lines of code
Queue queue = (Queue)context.lookup(replyToQueueName);
System.out.println("Setting the target to be non jms");
((MQQueue)queue).setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ);
QueueSender sender = session.createSender(queue);
then i get the following as the replyTo in the MDB (The MDB is configured with the help of a listener to a Queue in Websphere MQ)
queue:///<<Queue Manager>>/<<Local Queue>>?targetClient=1
I dont understand javascript:emoticon('') why i am getting ?targetClient=1 added to the replyTo queue specified in the request.
Within the mdb we do a jndi lookup to post a jms reply and we fail with the
CosNamingException (Because it is trying to lookup everything including the targetClient=1 and it doesnt find it).
Is there any configuration that i need to do anywhere (in WAS or in WMQ) to fix this problem ?
I would like to add that this used to work when we had MQ 5.3 and both the client and the was configuration has not changed. I did the following
1. Changed the target to be MQ instead of JMS in the websphere but it didnt help. I still got the same CosNaming when doing a jndi lookup
2. Tried the same in my other instance with WAS 6 and WMQ 5.3 and that worked with both MQSTR and MQRFH2.javascript:emoticon('')
I have the following questions?
1. How do i suppress the "targetClient" in the replyTo?
2. Why is Websphere adding it and why is it going away when doing with MQRFH2 .
Please
|
OK. You need to understand a property of the qcf in Version 6 and above which is called targetClientMatching. By default this is set to true.
I suspect that you are using neither the WAS MQ context for your destination nor the file context ...
I do not understand why you would want to do a lookup in JNDI for a destination that is provided as JMSReplyTo on the message.
You need to learn the difference between a JNDI lookup and a Destination URI (form "queue://QMGR/QUEUE?attr1=val1&attrn=valn").
You so nicely cast the destination to the MQQueue but did not enquire to the base queue name to do the lookup there...
Get back to the using java manual and  and  some more.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| 70033 |
| Posted: Fri Jan 02, 2009 11:20 am Post subject: Hope this helps !!! |
|
|
Apprentice
Joined: 22 Dec 2008
Posts: 27
|
|
| Back to top |
|
|
| 70033 |
| Posted: Fri Jan 02, 2009 11:26 am Post subject: Response.. |
|
|
Apprentice
Joined: 22 Dec 2008
Posts: 27
|
OK. You need to understand a property of the qcf in Version 6 and above which is called targetClientMatching. By default this is set to true.
I suspect that you are using neither the WAS MQ context for your destination nor the file context ...
I do not understand why you would want to do a lookup in JNDI for a destination that is provided as JMSReplyTo on the message.
The reason is that this could be different for different environment like UAT,Production ,etc . We could have had a property files but this was developed by someone else and we are just victims.
You need to learn the difference between a JNDI lookup and a Destination URI (form "queue://QMGR/QUEUE?attr1=val1&attrn=valn").
You so nicely cast the destination to the MQQueue but did not enquire to the base queue name to do the lookup there...
Yes what WAS/MQ has done is that the implementation has changed to pump in the targetClient between WMQ5.3 to WMQ 6. Look above for the url for another person who had the same problem . I agree that this is a an application wrongly parsing the jms uri but I also feel that the targetClient suppression should be the default behavior not the other way around.
Get back to the using java manual and and some more.
Thanx for the help . Please point me to the section which talks about how the behavior has changed from WMQ5.3 to WMQ 6 in any of your manuals. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jan 02, 2009 11:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The message that the MDB is replying to should have all of the necessary information contained in it, including the JMSReplyTo in a proper format.
You should never need, or be expecting to, use the value of JMSReplyTo as a lookup value for JNDI. It should be a sufficient destination on it's own!
There's no reason to go to JNDI. Just use the JMSReplyTo as a destination. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 02, 2009 3:29 pm Post subject: Re: Response.. |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| 70033 wrote: |
OK. You need to understand a property of the qcf in Version 6 and above which is called targetClientMatching. By default this is set to true.
I suspect that you are using neither the WAS MQ context for your destination nor the file context ...
I do not understand why you would want to do a lookup in JNDI for a destination that is provided as JMSReplyTo on the message.
The reason is that this could be different for different environment like UAT,Production ,etc . We could have had a property files but this was developed by someone else and we are just victims. |
I'm sure you're going to buy that ocean front property in Arizona the guy who told you this just offered you. The reason you are stating is so flawed it makes my skin crawl:
- If you can mix the environments there is something seriously wrong about your setup.
- If the server services multiple environments the JMSReplyTo destination on the message should take care of keeping the requesters separate. What if the reply to queue was to be a dynamic temporary queue. This could not possibly be in your JNDI. Even if the requesters use the same queue across environments the JMSCorrelationId on the reply message should be unique and allow them to identify precisely the response to the individual request (using the anonymous identifier pattern).
- There is no reason for a JNDI lookup here. If this is for an asynchronous consumption of the reply by an application that did not do the request, the requester is in charge of setting the JMSReplyTo destination so this should not be your responsibility as a Server program.
| 70033 wrote: |
You need to learn the difference between a JNDI lookup and a Destination URI (form "queue://QMGR/QUEUE?attr1=val1&attrn=valn").
You so nicely cast the destination to the MQQueue but did not enquire to the base queue name to do the lookup there...
Yes what WAS/MQ has done is that the implementation has changed to pump in the targetClient between WMQ5.3 to WMQ 6. Look above for the url for another person who had the same problem . I agree that this is a an application wrongly parsing the jms uri but I also feel that the targetClient suppression should be the default behavior not the other way around. |
No the default behavior of targetClientMatching=true is the right one in my mind. This way request without an RFH header get no RFH header on the reply whereas request using an RFH header get the RFH header on the reply.
| 70033 wrote: |
Get back to the using java manual and and some more.
Thanx for the help . Please point me to the section which talks about how the behavior has changed from WMQ5.3 to WMQ 6 in any of your manuals. |
See some of the new setups used in the resource adapter
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| 70033 |
| Posted: Mon Jan 05, 2009 8:27 am Post subject: Resolution.. |
|
|
Apprentice
Joined: 22 Dec 2008
Posts: 27
|
70033 wrote:
OK. You need to understand a property of the qcf in Version 6 and above which is called targetClientMatching. By default this is set to true.
I suspect that you are using neither the WAS MQ context for your destination nor the file context ...
I do not understand why you would want to do a lookup in JNDI for a destination that is provided as JMSReplyTo on the message.
The reason is that this could be different for different environment like UAT,Production ,etc . We could have had a property files but this was developed by someone else and we are just victims.
I'm sure you're going to buy that ocean front property in Arizona the guy who told you this just offered you. The reason you are stating is so flawed it makes my skin crawl:
* If you can mix the environments there is something seriously wrong about your setup.
No. There is no mix up of environments here. The design that we had was that the client specified the return queue and he did this because he needed the configurability across various environments.
* If the server services multiple environments the JMSReplyTo destination on the message should take care of keeping the requesters separate. What if the reply to queue was to be a dynamic temporary queue. This could not possibly be in your JNDI. Even if the requesters use the same queue across environments the JMSCorrelationId on the reply message should be unique and allow them to identify precisely the response to the individual request (using the anonymous identifier pattern).
I agree with you totally. We shouldnt have designed this way. We havent upgraded the code to keep up with the versions of WAS and that could be the reason is my feeling . Again this is inherited code .
* There is no reason for a JNDI lookup here. If this is for an asynchronous consumption of the reply by an application that did not do the request, the requester is in charge of setting the JMSReplyTo destination so this should not be your responsibility as a Server program.
Thanx for this suggestion .
70033 wrote:
You need to learn the difference between a JNDI lookup and a Destination URI (form "queue://QMGR/QUEUE?attr1=val1&attrn=valn").
You so nicely cast the destination to the MQQueue but did not enquire to the base queue name to do the lookup there...
Yes what WAS/MQ has done is that the implementation has changed to pump in the targetClient between WMQ5.3 to WMQ 6. Look above for the url for another person who had the same problem . I agree that this is a an application wrongly parsing the jms uri but I also feel that the targetClient suppression should be the default behavior not the other way around.
No the default behavior of targetClientMatching=true is the right one in my mind. This way request without an RFH header get no RFH header on the reply whereas request using an RFH header get the RFH header on the reply.
70033 wrote:
Get back to the using java manual and and some more.
Thanx for the help . Please point me to the section which talks about how the behavior has changed from WMQ5.3 to WMQ 6 in any of your manuals. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 05, 2009 12:25 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
|
| Back to top |
|
|
|
|
