qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nuno Santos <nsan...@redhat.com>
Subject Re: spec clarification regarding exception handling
Date Wed, 17 Jan 2007 20:34:50 GMT
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 <nsantos@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
>>
>>
> 
> 


Mime
View raw message