| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| During load test, msg routed to MQInput failure terminal |
« View previous topic :: View next topic » |
| Author |
Message
|
| pcelari |
 Posted: Mon Mar 26, 2007 7:18 am Post subject: During load test, msg routed to MQInput failure terminal |
 |
|
Chevalier
Joined: 31 Mar 2006
Posts: 411
Location: New York
|
In my simple msgflow there one MQInput, one MQOutput and a compute node that process request msg and creates result msg.
Individual tests runs perfectly well. However, when I run a load test, where request msg are put randomly at tight intervals to the MQInput node, the test runs fine for the initial minutes, then, suddenly request msg got routed to the queue connected to the failure terminal of the MQInput node.
What could be the cause of such behavior? Has anyone experienced this before?
_________________
pcelari
-----------------------------------------
- a master of always being a newbie |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Mar 26, 2007 7:28 am Post subject: Re: During load test, msg routed to MQInput failure terminal |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pcelari wrote: |
| What could be the cause of such behavior? |
I'd be inclined to stick some trace on the broker and ask it! 
Sounds (at the risk of being obvious) like a resource problem causing the compute node to abend (memory leak or similar).
Is it a "real" compute node or a Java compute node? Or not v6 at all?
Trace will tell the tale. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pcelari |
| Posted: Mon Mar 26, 2007 7:41 am Post subject: |
|
|
Chevalier
Joined: 31 Mar 2006
Posts: 411
Location: New York
|
It's a real compute node, where I call a stored procedure on a remote DB2 on z/OS. I think you're right on the resource issue.
But why don't the msg stay on the inputQ before broker resource become available again?
If I stop the incoming msg, wait for a little while. it works again until about a minutes later.
I set the MQInput to non-transactional, and "By Queue Order".
Remember at version 2.1, I can set a maximum number of flow instances running at the execution group level. That feature seems to have dissappeared, why?
_________________
pcelari
-----------------------------------------
- a master of always being a newbie |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 26, 2007 7:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pcelari wrote: |
But why don't the msg stay on the inputQ before broker resource become available again?
|
How would the flow know it's a transient resource issue? The message blew up, got rolled back as per design and found a failure node wired up, so reasonably enough it followed the failure flow.
Now if you wanted to design a flow that rolled the message back onto the input queue that would work. Clearly you'd need some kind of poison message logic - it might not be a transient error.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pcelari |
| Posted: Mon Mar 26, 2007 8:07 am Post subject: |
|
|
Chevalier
Joined: 31 Mar 2006
Posts: 411
Location: New York
|
thanks a lot for the insight. I better run a service trace to locate the point of failure. BTW. the broker runs on z/Linux.
On the webservice side, I know if you pipe requests too fast into the service, it may cause the service component to hang. (DoS attack).
I also tried to locate the problem by running the debugger, with breakpoint on the connection from failure terminal to the Failure node. But even the msg got on the failure queue, it never stops at the break point, so I can't even catch the point of failure.
Anyway, I'll run a service trace, but the file will probably be very large as it doesn't fail at definite time.
_________________
pcelari
-----------------------------------------
- a master of always being a newbie |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 26, 2007 8:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
IMHO a service trace is a bit of an overkill. User trace should at least show the exception code, proving resource or not as the problem.
Still, even if you run a service trace & get a huge file, disc is cheap and you can leave the search running while you grab a coffee (or other beverage of your choice)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pcelari |
| Posted: Mon Mar 26, 2007 3:14 pm Post subject: |
|
|
Chevalier
Joined: 31 Mar 2006
Posts: 411
Location: New York
|
The usertrace doesn't recored any problem. No words like "Failure" or "Error" exist in the formated output file.
However, the problem went away after I set the additional instances to 9 in the bar file. No performance gain though.
_________________
pcelari
-----------------------------------------
- a master of always being a newbie |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
