| Author |
Message
|
| Prasi |
 Posted: Sun Apr 22, 2012 2:52 am Post subject: Time out requests |
 |
|
Apprentice
Joined: 03 Aug 2011
Posts: 42
|
Hi,
When we fire multiple requests to broker among multiple requeest 1/2 are getting timed out. Timed out in the sense response is taking more than a minute and hence the receiving application is not able to pick up the message.
We have enabled traces and we found below as common.
| Code: |
2012-04-22 08:31:23.933674 12114 UserTrace BIP6060I: Parser type ''Properties'' created on behalf of node 'MF_CRYSTAL_MQ_GATEWAY.WMQ_Gateway_ReqIn.InputQueue' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2012-04-22 08:31:23.933730 12114 UserTrace BIP6061I: Parser type ''MQMD'' created on behalf of node 'MF_CRYSTAL_MQ_GATEWAY.WMQ_Gateway_ReqIn.InputQueue' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value ''MQHMD'' from previous parser.
2012-04-22 08:31:23.933778 12114 UserTrace BIP6061I: Parser type ''MQRFH2'' created on behalf of node 'MF_CRYSTAL_MQ_GATEWAY.WMQ_Gateway_ReqIn.InputQueue' to handle portion of incoming message of length '324' bytes beginning at offset '364'. Parser type selected based on value ''MQHRF2'' from previous parser.
[b]2012-04-22 08:31:23.933850 12114 UserTrace BIP6069W: The broker is not capable of handling a message of data type ''JMS_TEXT''.
The message broker received a message that requires the handling of data of type ''JMS_TEXT'', but the broker does not have the capability to handle data of this type. [/b]
Check both the message being sent to the message broker and the configuration data for the node. References to the unsupported data type must be removed if the message is to be processed by the broker.
2012-04-22 08:31:24.628924 12884 UserTrace BIP6060I: Parser type ''Properties'' created on behalf of node 'MF_CRYSTAL_MQ_GATEWAY.ReadServiceResponseMessage.InputQueue' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
[b]2012-04-22 08:31:24.628978 12884 UserTrace BIP6061I: Parser type ''MQMD'' created on behalf of node 'MF_CRYSTAL_MQ_GATEWAY.ReadServiceResponseMessage.InputQueue' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value ''MQHMD'' from previous parser.
2012-04-22 08:31:24.629004 12884 UserTrace BIP6069W: The broker is not capable of handling a message of data type ''MQSTR''.
The message broker received a message that requires the handling of data of type ''MQSTR'', but the broker does not have the capability to handle data of this type. [/b]
Check both the message being sent to the message broker and the configuration data for the node. References to the unsupported data type must be removed if the message is to be processed by the broker. |
|
|
| Back to top |
|
 |
| exerk |
| Posted: Sun Apr 22, 2012 2:57 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Moving this to the Broker forum, where it belongs...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Apr 22, 2012 6:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Start from point 0.
Ensure that all of the multiple requests you are firing are the same, baring any differences in business content.
If you are, for example, using two separate applications to send messages, then perhaps the reason why one half of the messages fail is that one half of the two applications is wrong. |
|
| Back to top |
|
|
| Prasi |
| Posted: Sun Apr 22, 2012 11:09 pm Post subject: |
|
|
Apprentice
Joined: 03 Aug 2011
Posts: 42
|
Thanks for the reply. But even for the same application out of 15 request 1 or 2 are taking time to respond.
Please help. |
|
| Back to top |
|
|
| Esa |
| Posted: Sun Apr 22, 2012 11:41 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
It seems you have two flows, WMQ_Gateway_ReqIn and ReadServiceResponseMessage. Or is ReadServiceResponseMessage.InputQueue an MQGet node?
There are other details you have not told us:
- do you send all the 15 messages at the same time?
- if you wait for the response before sending the next request, do you get the same results ( 1 or 2 requests of 15 getting timed out)?
- does you flow have additional instances enabled?
- is the endpoint application processing multiple requests simultaneously? Chrystal Reports?
| Prasi wrote: |
| When we fire multiple requests to broker among multiple requeest 1/2 are getting timed out. Timed out in the sense response is taking more than a minute and hence the receiving application is not able to pick up the message. |
You are not very clear here. Which application is the receiving application that gets timed out? MF_CRYSTAL_MQ_GATEWAY.ReadServiceResponseMessage?
The very short trace you have sent us seems to tell that the first node gets rubbish, but does not throw an exception. The second flow (or node) gets rubbish back from the endpoint in less than 1 second, but does not seem to throw an exception. This seems to be a typical rubbish in/rubbish out scenario. I cannot see any timeouts happening... |
|
| Back to top |
|
|
| Prasi |
| Posted: Tue May 08, 2012 12:14 pm Post subject: |
|
|
Apprentice
Joined: 03 Aug 2011
Posts: 42
|
WMQ_Gateway_ReqIn is an MQ Input node which receives the requests from application and for further processing to host.
ReadServiceResponseMessage is another MQ input node which receives the response from broker post transformation and sends to application.
15 messages are fired from application one after the other.
If i wait for the responses to come, in that case yes, 1 or 2 requests are getting timed out.
Additional instances is not enabled currently... Evn if enabled, it produces the same result.
yes the end point application also processes the requests simultaneously.
And more unique thing which we found is that after an idle amount of time say 10 minutes, if we fire the request, first request is getting timed out. Second one is getting processed fastly.
Please help. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 08, 2012 7:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Are you sure the time is not spent in a poorly optimized service application?
Like waiting for more than one min for data to come back from a DB because the query is forcing a full table scan? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Esa |
| Posted: Tue May 08, 2012 11:22 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
What kind of exception handling do you have in your flow? None?
Are you sure this is about timeouts? Perhaps the endpoint application gets nuts because of a sudden burst of requests and at some point starts sending empty or broken messages that fail in your response handling?
The trace you sent points to that direction... |
|
| Back to top |
|
|
|
|
