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 <[EMAIL PROTECTED]> 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
