| Author |
Message
|
| sam926 |
 Posted: Thu Oct 01, 2015 4:04 am Post subject: IIB10 WLM Policy to fail the messages |
 |
|
Novice
Joined: 01 Apr 2015
Posts: 13
|
Env - IIB10, Windows
WebServices flow using SOAP nodes, requirement is to take only certain number of messages/sec(ex:100/sec). Tried using WLM Policy threshold setting to achieve this. Does WLM help in this regard?
I'm able to receive notifications on the queue whenever there is an increase/decrease on the threshold value. I would like to redirect the messages beyond 100 to failure terminal on the SOAPInput node. But, this isn't working just with the policy threshold setting, as all the messages are getting passed successfully. Does WLM help to automatically fail the messages beyond the threshold count value? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Oct 01, 2015 4:56 am Post subject: Re: IIB10 WLM Policy to fail the messages |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sam926 wrote: |
| Does WLM help to automatically fail the messages beyond the threshold count value? |
No. What it will do is limit the flow to processing 100 transactions per second. It won't stop the HTTP requests stacking up on the listener and, if the receive rate is much in excess of 100 TPS, it's fair to assume that at some point the stack will fill and the calling apps will start getting 404 (403? 402? 40sorry-I'm-busy-call-back-later).
It won't explicitly route the "excess" messages in the time slice anywhere. You need a different technology, such as DataPower or a network packet shaper, to achieve that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sam926 |
| Posted: Tue Oct 06, 2015 7:11 am Post subject: |
|
|
Novice
Joined: 01 Apr 2015
Posts: 13
|
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 06, 2015 8:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sam926 wrote: |
| Delay - how can this be done for real time services? |
Explain to me the use case where this makes sense.
You are receiving real time calls at a rate of (say) 200 TPS. You only want to run at 100 TPS and for 50% of your customers to error out (you said you wanted the policy to route to the failure terminal).
Why do you want half of your customers to receive no service? By design?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 06, 2015 8:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The WLM policies queue up incoming messages until the next interval.
Obviously, if too many messages get queued up, then the ones on the end will eventually not get processed, and timed out.
You can only pass data to the fail terminal if the message actually reaches the input node.
You could, possibly, examine the incoming messages after the input node, and decide to fail them.
Although, again, the "why" is very hard to fathom.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| sam926 |
| Posted: Tue Oct 06, 2015 10:15 am Post subject: |
|
|
Novice
Joined: 01 Apr 2015
Posts: 13
|
| Quote: |
| Explain to me the use case where this makes sense. |
I should have mentioned clearly about my query in the previous post. Nah, there is no use case for delay and I have no intention to delay the messages. Yes, there is a requirement to check whether IIB can redirect messages to failure terminal in case of excess messages. This cannot be done in a simple way, I'm just trying to understand how WLM policy remaining goals work and intend to know how delay works.
Thanks for the clarification! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 06, 2015 10:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| sam926 wrote: |
intend to know how delay works.
Thanks for the clarification! |
Again, incoming requests after the WLM policy limit are queued (internally) until the next workload iteration. Then they are processed.
Again, if you have, say, 500 messages come in within a second, and your policy says you can only process 100 messages per second, then the remaining 400 will be processed at 100 per second until they are gone.
This could easily cause many of them to timeout or expire or etc. before they reach the input node.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 06, 2015 10:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sam926 wrote: |
| Yes, there is a requirement to check whether IIB can redirect messages to failure terminal in case of excess messages. |
Again, why would you direct "excess" messages to the failure terminal?
| sam926 wrote: |
| intend to know how delay works. |
Exactly as documented and exactly as described.
Consider where your real time service isn't hosted on IIB but by another platform (we'll say WAS) that's constrained by resource or application design. If IIB is being used as a protocol bridge from WMQ to web service, it's highly possible that IIB could make web service calls much faster than the application can process them (leading to the errors described above) and you'd put a policy in place to constrain IIB to a TPS rate within the reach of the target web service.
So the fact this doesn't work so great for real time services hosted by IIB (for the reasons discussed above), it works great in a variety of other circumstances.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
