validate-address warning

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

validate-address warning

Alexey Loubyansky
I just noticed that if validate-address has a negative result there is a
WARN in the server's log. Do we really need that?
I just realized that CLI may cause quite a lot of those.

[Host Controller] 13:34:50,256 WARN  [org.jboss.as.controller]
(pool-3-thread-6) Operation ("validate-address") failed - address:
([("subsystem" => "messaging")])

Thanks,
Alexey
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: validate-address warning

Brian Stansberry
On 7/18/11 6:40 AM, Alexey Loubyansky wrote:
> I just noticed that if validate-address has a negative result there is a
> WARN in the server's log. Do we really need that?

No.

> I just realized that CLI may cause quite a lot of those.
>
> [Host Controller] 13:34:50,256 WARN  [org.jboss.as.controller]
> (pool-3-thread-6) Operation ("validate-address") failed - address:
> ([("subsystem" =>  "messaging")])
>

I wonder why it's happening? That message gets logged if the step
handler throws OperationFailedException, and this handler doesn't.

The intent is a handler throws an OFE if there is an error in the user
request, and we WARN log it instead of ERROR because it's not an error
condition on the server. This handler shouldn't throw an OFE though
because it's not an error condition. But it doesn't!

Oh, I bet I know why; the theory of the handler is somewhat off. If you
invoke /interface=bogusname:validate-address, it will work, because the
handler is (indirectly) registered under /interface=*. But if you do
/bogustype=public:validate-address, it doesn't work as expected as
nothing is registered under /bogustype=*. So you are seeing the standard
"unknown address" handling.

Probably the right way to implement this is to have validate-address
only on the root resource and then pass the address as a param.

> Thanks,
> Alexey
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: validate-address warning

Alexey Loubyansky
On 07/18/2011 04:32 PM, Brian Stansberry wrote:

> On 7/18/11 6:40 AM, Alexey Loubyansky wrote:
>> I just noticed that if validate-address has a negative result there is a
>> WARN in the server's log. Do we really need that?
>
> No.
>
>> I just realized that CLI may cause quite a lot of those.
>>
>> [Host Controller] 13:34:50,256 WARN  [org.jboss.as.controller]
>> (pool-3-thread-6) Operation ("validate-address") failed - address:
>> ([("subsystem" =>   "messaging")])
>>
>
> I wonder why it's happening? That message gets logged if the step
> handler throws OperationFailedException, and this handler doesn't.
>
> The intent is a handler throws an OFE if there is an error in the user
> request, and we WARN log it instead of ERROR because it's not an error
> condition on the server. This handler shouldn't throw an OFE though
> because it's not an error condition. But it doesn't!
>
> Oh, I bet I know why; the theory of the handler is somewhat off. If you
> invoke /interface=bogusname:validate-address, it will work, because the
> handler is (indirectly) registered under /interface=*. But if you do
> /bogustype=public:validate-address, it doesn't work as expected as
> nothing is registered under /bogustype=*. So you are seeing the standard
> "unknown address" handling.

Ok, it's a bit confusing. Normally you shouldn't see those WARN caused
by the CLI (i.e. it does almost everything right :). But if you want to
reproduce the issue, start a standalone server, connect the cli, stop
the server and start the domain w/o re-connecting the cli, i.e. it'll
still show [standalone@...] prompt. Then press tab to complete commands.

It'll check if the messaging subsystem is there (/subsystem=messaging)
to include or exclude the jms commands. And it does it on every empty
line tab-completion (the results could be cached though).

Alexey
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: validate-address warning

Brian Stansberry
On 7/18/11 10:45 AM, Alexey Loubyansky wrote:

> On 07/18/2011 04:32 PM, Brian Stansberry wrote:
>> On 7/18/11 6:40 AM, Alexey Loubyansky wrote:
>>> I just noticed that if validate-address has a negative result there is a
>>> WARN in the server's log. Do we really need that?
>>
>> No.
>>
>>> I just realized that CLI may cause quite a lot of those.
>>>
>>> [Host Controller] 13:34:50,256 WARN  [org.jboss.as.controller]
>>> (pool-3-thread-6) Operation ("validate-address") failed - address:
>>> ([("subsystem" =>    "messaging")])
>>>
>>
>> I wonder why it's happening? That message gets logged if the step
>> handler throws OperationFailedException, and this handler doesn't.
>>
>> The intent is a handler throws an OFE if there is an error in the user
>> request, and we WARN log it instead of ERROR because it's not an error
>> condition on the server. This handler shouldn't throw an OFE though
>> because it's not an error condition. But it doesn't!
>>
>> Oh, I bet I know why; the theory of the handler is somewhat off. If you
>> invoke /interface=bogusname:validate-address, it will work, because the
>> handler is (indirectly) registered under /interface=*. But if you do
>> /bogustype=public:validate-address, it doesn't work as expected as
>> nothing is registered under /bogustype=*. So you are seeing the standard
>> "unknown address" handling.
>
> Ok, it's a bit confusing. Normally you shouldn't see those WARN caused
> by the CLI (i.e. it does almost everything right :). But if you want to
> reproduce the issue, start a standalone server, connect the cli, stop
> the server and start the domain w/o re-connecting the cli, i.e. it'll
> still show [standalone@...] prompt. Then press tab to complete commands.
>
> It'll check if the messaging subsystem is there (/subsystem=messaging)
> to include or exclude the jms commands. And it does it on every empty
> line tab-completion (the results could be cached though).

Yep; that's the scenario I describe. In a domain, address
/subsystem=anything is equivalent to /boguschildtype=anything, since
subsystem is not a valid child type of the root domain resource.

I think the solution is to make the address a param. This could be done
without breaking the existing op by making it an optional parameter,
with the value used to validate an address relative to the address being
invoked against.

:validate-address(address=[(subsystem=messaging)])

That's less user friendly than /subsystem=messaging:validate-address,
but I doubt somewhat nonsophisticated users will invoke this op.

Hmm, I'll look into an alternative: having handling of invalid
address/op combos not trigger a WARN; perhaps that is easy to do.

>
> Alexey
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: validate-address warning

Emanuel Muckenhuber

Hmm, i actually added this operation, so i can stick it at the top of an
composite operation, where it would fail immediately rather than
somewhere during the validation stage. In particular our secure .cli
scripts, since there are no further scripting capabilities. However i
thought i registered this operation as Private - obviously out of this
context this behavior does not make much sense.

On 07/18/2011 06:39 PM, Brian Stansberry wrote:

> On 7/18/11 10:45 AM, Alexey Loubyansky wrote:
>> On 07/18/2011 04:32 PM, Brian Stansberry wrote:
>>> On 7/18/11 6:40 AM, Alexey Loubyansky wrote:
>>>> I just noticed that if validate-address has a negative result there is a
>>>> WARN in the server's log. Do we really need that?
>>>
>>> No.
>>>
>>>> I just realized that CLI may cause quite a lot of those.
>>>>
>>>> [Host Controller] 13:34:50,256 WARN  [org.jboss.as.controller]
>>>> (pool-3-thread-6) Operation ("validate-address") failed - address:
>>>> ([("subsystem" =>     "messaging")])
>>>>
>>>
>>> I wonder why it's happening? That message gets logged if the step
>>> handler throws OperationFailedException, and this handler doesn't.
>>>
>>> The intent is a handler throws an OFE if there is an error in the user
>>> request, and we WARN log it instead of ERROR because it's not an error
>>> condition on the server. This handler shouldn't throw an OFE though
>>> because it's not an error condition. But it doesn't!
>>>
>>> Oh, I bet I know why; the theory of the handler is somewhat off. If you
>>> invoke /interface=bogusname:validate-address, it will work, because the
>>> handler is (indirectly) registered under /interface=*. But if you do
>>> /bogustype=public:validate-address, it doesn't work as expected as
>>> nothing is registered under /bogustype=*. So you are seeing the standard
>>> "unknown address" handling.
>>
>> Ok, it's a bit confusing. Normally you shouldn't see those WARN caused
>> by the CLI (i.e. it does almost everything right :). But if you want to
>> reproduce the issue, start a standalone server, connect the cli, stop
>> the server and start the domain w/o re-connecting the cli, i.e. it'll
>> still show [standalone@...] prompt. Then press tab to complete commands.
>>
>> It'll check if the messaging subsystem is there (/subsystem=messaging)
>> to include or exclude the jms commands. And it does it on every empty
>> line tab-completion (the results could be cached though).
>
> Yep; that's the scenario I describe. In a domain, address
> /subsystem=anything is equivalent to /boguschildtype=anything, since
> subsystem is not a valid child type of the root domain resource.
>
> I think the solution is to make the address a param. This could be done
> without breaking the existing op by making it an optional parameter,
> with the value used to validate an address relative to the address being
> invoked against.
>
> :validate-address(address=[(subsystem=messaging)])
>
> That's less user friendly than /subsystem=messaging:validate-address,
> but I doubt somewhat nonsophisticated users will invoke this op.
>
> Hmm, I'll look into an alternative: having handling of invalid
> address/op combos not trigger a WARN; perhaps that is easy to do.
>
>>
>> Alexey
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev