spec clarification regarding exception handling

[Nuno Santos <ns...@redhat.com>]

I came across a scenario in the Java broker code that's not clearly
outlined in the AMQP spec, and was hoping to get some pointers on how to
proceed.

The issue is when a client attempts to create more channels than the
connection's negotiated maximum value... as it stands now, the Java
broker happily creates the requested channels, regardless of the limit.

I entered a JIRA for this --
https://issues.apache.org/jira/browse/QPID-290 -- and uploaded a patch
that raises an exception when that situation occurs. However, since the
exception is at the connection level (the channel won't be created, so
can't be at channel level), that means that the whole connection is
brought down due to a somewhat benign error.

There are two questions here:

1) the spec is vague on exactly what exception / error code should be
triggered in this scenario, if any.

2) in the event that an exception should be triggered (and my feeling is
that it should, as the client is breaking the negotiated connection
parameters), then the spec should clarify what action to take: the
"default" action of bringing down the connection, or something a little
less drastic but that would stray from the standard exception semantics.

FWIW I tentatively picked 530/not-allowed to use in my patch, as this 
may fit under the "other criteria" mentioned in the spec: "The client 
tried to work with some entity in a manner that is prohibited by the 
server, due to security settings or by some other criteria."

Still, this does not seem like the appropriate response as closing the 
connection does not feel right. I am thinking that we should request the 
AMQP Working Group to errata another error code for this purpose.

I would appreciate any input from the list before taking it to the AMQP 
Working Group and requesting a new error code.

Thanks,
Nuno

Re: spec clarification regarding exception handling

[Nuno Santos <ns...@redhat.com>]

Alan Conway wrote:
> I think you should raise this issue on the AMQ WG list. It has been
> discussed before and there are strong opinions on various sides, it may
> be ripe for a hammering out. Personally I'm still on the fence :) 
> Until we agree on something else at the AMQP level I think we should
> implement the current model - its harsh but consistent and
> interoperable.

OK, I'll bring this issue up on the AMQP list, I agree it's a protocol 
and not an implementation decision... fwiw, the patch I uploaded to the 
JIRA does implement the default action of bringing the connection down.

Thanks,
Nuno

Re: spec clarification regarding exception handling

[Alan Conway <ac...@redhat.com>]

On Wed, 2007-01-17 at 15:34 -0500, Nuno Santos wrote:
> Martin Ritchie wrote:
> > My understanding is that closing the connection is the correct
> > approach when a client does something wrong.
> 
> I agree that's the default action that the spec mandates for other 
> errors, I just feel it's too harsh for this particular scenario -- 
> attempting to create a channel and having the creation fail isn't a big 
> deal, I don't think it justifies taking down the whole connection... I 
> can see the other side of the argument, though, that since the client 
> knows the threshold it shouldn't be attempting to create channels beyond 
> that limit.
> 
I think you should raise this issue on the AMQ WG list. It has been
discussed before and there are strong opinions on various sides, it may
be ripe for a hammering out. Personally I'm still on the fence :) 
Until we agree on something else at the AMQP level I think we should
implement the current model - its harsh but consistent and
interoperable.

Re: spec clarification regarding exception handling

[Nuno Santos <ns...@redhat.com>]

Martin Ritchie wrote:
> My understanding is that closing the connection is the correct
> approach when a client does something wrong.

I agree that's the default action that the spec mandates for other 
errors, I just feel it's too harsh for this particular scenario -- 
attempting to create a channel and having the creation fail isn't a big 
deal, I don't think it justifies taking down the whole connection... I 
can see the other side of the argument, though, that since the client 
knows the threshold it shouldn't be attempting to create channels beyond 
that limit.

Nuno

> 
> On 16/01/07, Nuno Santos <ns...@redhat.com> wrote:
>>
>> I came across a scenario in the Java broker code that's not clearly
>> outlined in the AMQP spec, and was hoping to get some pointers on how to
>> proceed.
>>
>> The issue is when a client attempts to create more channels than the
>> connection's negotiated maximum value... as it stands now, the Java
>> broker happily creates the requested channels, regardless of the limit.
>>
>> I entered a JIRA for this --
>> https://issues.apache.org/jira/browse/QPID-290 -- and uploaded a patch
>> that raises an exception when that situation occurs. However, since the
>> exception is at the connection level (the channel won't be created, so
>> can't be at channel level), that means that the whole connection is
>> brought down due to a somewhat benign error.
>>
>> There are two questions here:
>>
>> 1) the spec is vague on exactly what exception / error code should be
>> triggered in this scenario, if any.
>>
>> 2) in the event that an exception should be triggered (and my feeling is
>> that it should, as the client is breaking the negotiated connection
>> parameters), then the spec should clarify what action to take: the
>> "default" action of bringing down the connection, or something a little
>> less drastic but that would stray from the standard exception semantics.
>>
>> FWIW I tentatively picked 530/not-allowed to use in my patch, as this
>> may fit under the "other criteria" mentioned in the spec: "The client
>> tried to work with some entity in a manner that is prohibited by the
>> server, due to security settings or by some other criteria."
>>
>> Still, this does not seem like the appropriate response as closing the
>> connection does not feel right. I am thinking that we should request the
>> AMQP Working Group to errata another error code for this purpose.
>>
>> I would appreciate any input from the list before taking it to the AMQP
>> Working Group and requesting a new error code.
>>
>> Thanks,
>> Nuno
>>
>>
> 
> 

Re: spec clarification regarding exception handling

[Martin Ritchie <ri...@apache.org>]

My understanding is that closing the connection is the correct
approach when a client does something wrong.

On 16/01/07, Nuno Santos <ns...@redhat.com> wrote:
>
> I came across a scenario in the Java broker code that's not clearly
> outlined in the AMQP spec, and was hoping to get some pointers on how to
> proceed.
>
> The issue is when a client attempts to create more channels than the
> connection's negotiated maximum value... as it stands now, the Java
> broker happily creates the requested channels, regardless of the limit.
>
> I entered a JIRA for this --
> https://issues.apache.org/jira/browse/QPID-290 -- and uploaded a patch
> that raises an exception when that situation occurs. However, since the
> exception is at the connection level (the channel won't be created, so
> can't be at channel level), that means that the whole connection is
> brought down due to a somewhat benign error.
>
> There are two questions here:
>
> 1) the spec is vague on exactly what exception / error code should be
> triggered in this scenario, if any.
>
> 2) in the event that an exception should be triggered (and my feeling is
> that it should, as the client is breaking the negotiated connection
> parameters), then the spec should clarify what action to take: the
> "default" action of bringing down the connection, or something a little
> less drastic but that would stray from the standard exception semantics.
>
> FWIW I tentatively picked 530/not-allowed to use in my patch, as this
> may fit under the "other criteria" mentioned in the spec: "The client
> tried to work with some entity in a manner that is prohibited by the
> server, due to security settings or by some other criteria."
>
> Still, this does not seem like the appropriate response as closing the
> connection does not feel right. I am thinking that we should request the
> AMQP Working Group to errata another error code for this purpose.
>
> I would appreciate any input from the list before taking it to the AMQP
> Working Group and requesting a new error code.
>
> Thanks,
> Nuno
>
>


-- 
Martin Ritchie