Author |
Message
|
BosmanGH |
Posted: Fri Sep 07, 2007 1:27 pm Post subject: JMS REQUEST answered with DATAGRAM is not recieved in WAS |
|
|
Newbie
Joined: 07 Sep 2007 Posts: 7
|
For our application we've implemented request / reply messaging.
We are using Websphere App. Server 6 and JMS.
The pattern used is the "CorrelationId pattern", the CorrId from the request is placed in the correlationId of the response.
The messageType sent by us is REQUEST, the messagetype send back by our service provider is DATAGRAM.
The following occurs: after sending a request no message is found or matched (using our JMS request/reply implementation) in the container.
We confirmed that the message was sent by the provider.
Also: When using a separate java (non jms) mq application to check the queue nothing is found. But when (the implementation in) the container times out, the separate java application recieves the message!!
Questions:
1. We generate our Correlation ID and set it using setJMSCorrelationId. Would every string be correct?
2. Our provider uses DATAGRAM. We wanted REPLY, but they are not willing to implement this change. Would this change help?
3. Who can tell why the reply message is not found or matched in Websphere Application Server?
4. Is there some kind of locking mechanism on the queue? Because the separate application only recieved the message after a timeout of the WAS container. |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Sep 07, 2007 2:04 pm Post subject: Re: JMS REQUEST answered with DATAGRAM is not recieved in WA |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
BosmanGH wrote: |
4. Is there some kind of locking mechanism on the queue? Because the separate application only recieved the message after a timeout of the WAS container. |
JMS is transactional. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Sep 07, 2007 4:58 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
To be more clear you need 2 transactions.
Right now you only have one.
Remember WAS overrides any transactional settings you might have specified for the JMS Session...
What does that mean?
Well the message does not get sent / is not available until the global transaction it participates in is committed. This is why you receive the reply only after the timeout... because that is when you commit the request...
In other words until the request is committed it is pointless to wait for an answer...
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
BosmanGH |
Posted: Sun Sep 09, 2007 10:53 am Post subject: |
|
|
Newbie
Joined: 07 Sep 2007 Posts: 7
|
Ok, this seems logical to me.
But why is the response not read during the transaction? Could the DATAGRAM messagetype or the incorrect CorrelationId be the reason? |
|
Back to top |
|
 |
jefflowrey |
Posted: Sun Sep 09, 2007 2:38 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
How can the response be created, if the request hasn't been sent? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
BosmanGH |
Posted: Sun Sep 09, 2007 10:53 pm Post subject: |
|
|
Newbie
Joined: 07 Sep 2007 Posts: 7
|
Well, we confirmed that the reply message (as response on the request sent by us) was sent by our serviceprovider.
We are sure that this reply was put to the correct queue, but JMS / WAS 6 could not recieve it, or WAS was not able to match it.
The response was only recieved with another application using no JMS, but plain Java/MQ. This could only be accomplished when WAS timed out. |
|
Back to top |
|
 |
Vitor |
Posted: Sun Sep 09, 2007 11:26 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
I think what people are getting at is the request is not being received until WAS times out because the commit is not happening until that point. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Sep 10, 2007 2:15 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
fjb_saper wrote: |
To be more clear you need 2 transactions.
Right now you only have one.
Remember WAS overrides any transactional settings you might have specified for the JMS Session...
What does that mean?
Well the message does not get sent / is not available until the global transaction it participates in is committed. This is why you receive the reply only after the timeout... because that is when you commit the request...
In other words until the request is committed it is pointless to wait for an answer...
Enjoy  |
_________________ MQ & Broker admin |
|
Back to top |
|
 |
BosmanGH |
Posted: Mon Sep 10, 2007 2:41 am Post subject: |
|
|
Newbie
Joined: 07 Sep 2007 Posts: 7
|
Do I need to set the following setting in the request message?
JMS_IBM_Report_Pass_Correl_ID |
|
Back to top |
|
 |
Vitor |
Posted: Mon Sep 10, 2007 2:52 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
BosmanGH wrote: |
Do I need to set the following setting in the request message? |
Possibly, but this has nothing to do with the solution we're suggesting. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Sep 10, 2007 2:58 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
BosmanGH wrote: |
Do I need to set the following setting in the request message?
JMS_IBM_Report_Pass_Correl_ID |
Which part in bold of my highlighted message do you not understand?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Vitor |
Posted: Mon Sep 10, 2007 3:04 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
fjb_saper wrote: |
BosmanGH wrote: |
Do I need to set the following setting in the request message?
JMS_IBM_Report_Pass_Correl_ID |
Which part in bold of my highlighted message do you not understand?  |
All of it apparently.....
*slaps wrist*  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
BosmanGH |
Posted: Mon Sep 10, 2007 3:35 am Post subject: |
|
|
Newbie
Joined: 07 Sep 2007 Posts: 7
|
If you could make clear why we should change the transactional settings, we would. But I'm not sure if this would be the key.
Currently we have several request - reply mechanisms working correctly.
They are invoked from one of our business SSB's and processed by another SSB, which has the send and recieve JMS implementation.
Every SSB-EJB has the <transaction-type> set on Container, but the send and recieve methods have the setting "Not supported".
This works correct for all messages sent using the pattern where the messageID, which is generated by default, is copied to the correlationId of the response.
For this particular situation as described in my first post our provider demands else: the pattern used is copy req_correlationID to resp_Correlation ID, and the provider returns messagetype datagram.
Why is Websphere not able to match the outgoing and incoming message, or does the message not even arrive? |
|
Back to top |
|
 |
BosmanGH |
Posted: Mon Sep 10, 2007 3:38 am Post subject: |
|
|
Newbie
Joined: 07 Sep 2007 Posts: 7
|
btw: what does slaps wrist mean?
English is not my native language...... |
|
Back to top |
|
 |
Vitor |
Posted: Mon Sep 10, 2007 3:49 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
BosmanGH wrote: |
btw: what does slaps wrist mean?
English is not my native language...... |
Nothing relevent or indeed professional. I apologise for a momentary lapse in a moment of weakness (it's a bad day here!)  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|