| Author |
Message
|
| Esa |
 Posted: Thu Mar 15, 2012 4:24 am Post subject: MQInput failure terminal |
 |
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
This question must have been discussed several times. The problem is that it has probably been discussed too many times: I could not find any relevant topics that addressed this specific aspect.
I caused a security exception in an MQInput node. The message was propagated to failure terminal, as expected. When debugging the flow after failure terminal I found out that the message had backout count of 1 and the ExceptionList contained the standard "dequed message" exception.
Tested it in 6.1.0.5 and 8.0 with the same results.
Why does MQInput node issue a completely unnecessary backout before propagating the message to failure terminal after an internal exception?
This way the original cause of the exception gets lost and cannot be handled by the flow - written in an audit log, for example.
Even if I checked 'Treat security exceptions as normal exceptions', the message was propagated to failure terminal with backout count of 1, which is not in line with what the InfoCenter says:
| Quote: |
| This property specifies whether to treat security exceptions (such as "Access Denied") as normal exceptions, and propagate them to the Failure terminal (if wired). This property is turned off by default, which ensures that security exceptions cause the message to be backed out even if the Failure terminal is wired. |
|
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Mar 15, 2012 5:05 am Post subject: Re: MQInput failure terminal |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Esa wrote: |
Even if I checked 'Treat security exceptions as normal exceptions', the message was propagated to failure terminal with backout count of 1, which is not in line with what the InfoCenter says:
| Quote: |
| This property specifies whether to treat security exceptions (such as "Access Denied") as normal exceptions, and propagate them to the Failure terminal (if wired). This property is turned off by default, which ensures that security exceptions cause the message to be backed out even if the Failure terminal is wired. |
|
If the observed behaviour of the product is at variance with the documented behaviour, the correct response is always a PMR. If only to get the documentation fixed!
This would also result in an authoritative answer on why it does this if it's supposed to do this. I would theorise that whatever method you used to create a security exception in the node (which you don't mention) was not treated as a security exception by the node (which could well be a problem in itself, which brings us back to the PMR).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Mar 15, 2012 5:36 am Post subject: Re: MQInput failure terminal |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Vitor wrote: |
| I would theorise that whatever method you used to create a security exception in the node (which you don't mention) was not treated as a security exception by the node (which could well be a problem in itself, which brings us back to the PMR). |
Clever deduction. Yes, there were many possible causes of exception in the setup: the message was missing credentials and the credentials to be used when the broker should authenticate with the LDAP server were missing. But because the exceptionlist was thrown away when the message was backed up there is no way to tell which one came first: a security exception (like missing creadentials) or a security-related exception (could not connect to the LDAP server).
But if we assume that MQInput works properly it obviously was some security related exception that is not classified as a security exception that came first. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Mar 15, 2012 5:44 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Then it is time for you to do the 'Must Gather' steps and take that ServiceTrace of the ExecutionGroup...
Come on, you know you really want to... 
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 15, 2012 5:45 am Post subject: Re: MQInput failure terminal |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Esa wrote: |
| But if we assume ... |
Ah, how many conversations have foundered on the rocks of that construction?
I'm sticking with a PMR. If only to get an explaination of what's happening.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 15, 2012 5:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| Then it is time for you to do the 'Must Gather' steps |
| smdavies99 wrote: |
| Come on, you know you really want to... |
IHMO you need a hobby. 
But MustGather & PMR. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Mar 15, 2012 6:14 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Vitor wrote: |
IHMO you need a hobby.
|
IMHO you need an acronym checker 
Do you mean I need a life?
Well, my test is in fact related to a real business case...
I will have to run a test in an environment where I can make sure that the exception will be an "Access denied" security exception and nothing else.
A message cannot end up in the failure terminal of an MQInput node without having to be backed out first. That is the way Message Broker has worked for ten years. Most exception handling routines rely on the fact that the message will be backed out if you throw an exception in the catch path.
But if the exception clearly happens within the MQInput node itself, like security and validation failures, why must the message be backed out before it is propagated to failure?
| Quote: |
| This property is turned off by default, which ensures that security exceptions cause the message to be backed out even if the Failure terminal is wired. |
Why is it so important to ensure that the message is backed out before it is propagated to failure? I cannot see any reason.  |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 15, 2012 6:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Esa wrote: |
| Vitor wrote: |
IHMO you need a hobby.
|
Do you mean I need a life? |
My comment was directed at smdavies99 for suggesting that going through the MustGather is some kind of fun activity that is anticipated in the same way my niece anticipates a trip to the zoo. That's why I quoted his comment rather than one of yours. 
| Esa wrote: |
| IMHO you need an acronym checker |
No, just more dyslexia medication.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Mar 15, 2012 7:10 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Code: |
| This property is turned off by default, which ensures that security exceptions cause the message to be backed out even if the Failure terminal is wired. |
Now I have tested this with a sure authentication failure and it worked as it should. The message was not backed out and the exceptionlist in failure path contained a SecurityException.
No reason to raise a PRM. It is working as documented.
But, as I just have proven, there may happen other exceptions in MQInput that are not security exceptions (instances of SecurityException). These exceptions simply cannot be handled as normal exceptions and the exceptionlist gets lost when the message is backed out.
I would like to have "Treat security exceptions like normal exceptions" enabled by default.
And actually I would have it to read "Treat exceptions like normal exceptions".
And I cannot see any reason why not.
Occupy Hursley! |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 15, 2012 7:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Esa wrote: |
| Occupy Hursley! |
There are more profitable and productive courses of action open to you.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Mar 15, 2012 7:24 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Don't worry, I was not serious. And I don't have the swords and horses for that.
Neither do I wan to fill in a product enhancement form.
I just want to raise some discussion. Not about my swords and horses but the way MQInput node discriminates rogue exceptions.
Hoping someone may give a reasonable explanation... |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Thu Mar 15, 2012 8:14 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
The explanation might be that exception handling is not part of the C language.... Broker/ESQL somehow implements it (probably with a library)... security exceptions are new (Version 6.0 to 6.1)... there is something that IBM thought they should do differently with them (though they provide a check-box).
That must be enough wild guesses for today (to feed your imagination) 
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| mgk |
| Posted: Thu Mar 15, 2012 8:38 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| A message cannot end up in the failure terminal of an MQInput node without having to be backed out first |
This is not entirely true. The model for Failure terminals is that exceptions that happen within a node are propagated to the failure terminal of that node if wired. If the failure terminal is not wired, the exception is thrown back up the flow, or if it is an Input node that supports backout (MQInput for example) then it is backed out. An example of this would be a validation failure when immediate validation was selected.
As for the security exceptions tick box the infocenter says: "This property specifies whether to treat security exceptions (such as "Access Denied") as normal exceptions, and propagate them to the Failure terminal (if wired). This property is turned off by default, which ensures that security exceptions cause the message to be backed out even if the Failure terminal is wired."
Kind Regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Mar 15, 2012 11:10 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| mgk wrote: |
| Quote: |
| A message cannot end up in the failure terminal of an MQInput node without having to be backed out first |
This is not entirely true. The model for Failure terminals is that exceptions that happen within a node are propagated to the failure terminal of that node if wired. If the failure terminal is not wired, the exception is thrown back up the flow, or if it is an Input node that supports backout (MQInput for example) then it is backed out. An example of this would be a validation failure when immediate validation was selected. |
Yes, that is the way it should be. The reason for my post is that checking "Treat security exceptions like normal exceptions" seems to be the only way to get a message with backout count of 0 in the failure terminal after an exception that happende within MQInput node.
| mgk wrote: |
| As for the security exceptions tick box the infocenter says: "This property specifies whether to treat security exceptions (such as "Access Denied") as normal exceptions, and propagate them to the Failure terminal (if wired). This property is turned off by default, which ensures that security exceptions cause the message to be backed out even if the Failure terminal is wired." |
This paragraph has been quoted several times in this thread. My question is: why the property is turned off by default. It does not protect the flow against denial of service attacts with unauthorized messages, for example ( on the contrary, it makes such an attack more effective by adding the backout operation). There must be another reason. Or must have been at some stage... |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Mar 15, 2012 11:35 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
A DOS attack on an MQInput node is a whole different ball game to one on an HTTP Server.
for one, you are in total control unless you have somehow exposed your Queue Manager to the outside world...
In general and excepting clients, a WMQ Environment is a closed world. Every access is (or should be) explicitly authorised.
Then you can restrict client access using SSL etc.
IMHO, that leaves a so called 'DOS' attack down to an application failure.
My preferred setup here is to NEVER let 'Application' clients access the Broker Qmgr directly. Alway go via a front end queue manager. Then you can put procedures in place to track down the rogue application.
Unless, what you are referring to as a DOS attack is (in the words of Monty Python),
Something completely different.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
