Best regards, Julien
Avitech GmbH Engineering AxL Tel.: +49 (0)7541/282-177 Fax: +49 (0)7541/282-199 e-mail: [email protected] ________________________________________________ Avitech GmbH Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany Court Registration: Amtsgericht Ulm | HRB 728293 Geschäftsführer/Managing Director: Jon Joseba Goyarzu Caño http://avitech.aero This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. -----Ursprüngliche Nachricht----- Von: Rob Godfrey [mailto:[email protected]] Gesendet: Freitag, 4. März 2016 15:34 An: [email protected] Betreff: Re: potential java broker REST API bug Raised JIRAs https://issues.apache.org/jira/browse/QPID-7124 and https://issues.apache.org/jira/browse/QPID-7125 to cover the issues brought up here. -- Rob On 4 March 2016 at 14:06, Rob Godfrey <[email protected]> wrote: > > > On 4 March 2016 at 13:49, Julien Charon <[email protected]> > wrote: > >> Hi, >> >> >> I'm currently doing some tests with the java broker's REST API >> (6.0.1), mainly queue management, i.e. GET, PUT, DELETE and ran into >> something strange. >> Assuming the broker is running on localhost and on port 8080, I can >> perform following requests: >> GET: http://localhost:8080/api/latest/queue will return all defined >> queues, even those not defined on the default vhost / vhostnode >> DELETE: http://localhost:8080/api/latest/queue?name=newQueue will >> delete queue with name "newQueue" >> >> But >> PUT: http://localhost:8080/api/latest/queue with body content {"name": >> "newQueue"} will result in an error (HTTP status 500 and a >> java.lang.IndexOutOfBoundsException in the broker's logs). >> > > > OK - that should fail more gracefully... but it does need to fail as a > queue must be created within the context of a virtual host... since > there is no path to a virtual host here, it doesn't know where to put > the queue > > >> PUT: http://localhost:8080/api/latest/queue/newQueue with body >> content {} will result in an error, too (HTTP status 422 and >> errorMessage "Either parent path or full object path must be >> specified on object creation. Full object path must be specified on >> object update. Found [] of size 0 expecting 3") >> >> > Not a particularly helpful error message, but failure is the correct > response here, as per the above > > > >> PUT: http://localhost:8080/api/latest/queue/default/default/newQueue >> with body content {} >> and >> PUT: http://localhost:8080/api/latest/queue/default/default with body >> content {"name": "newQueue"} will succeed. >> >> Is that somehow intended or is it a bug? I would have expected the >> queue to be created for the virtual host (node) configured as default either >> ways. >> >> > Nope - the default is really only about AMQP connections where a > virtual host has not been specified... the REST API doesn't use the > default (or virtual host aliases) to locate virtual hosts - it works > purely off the actual configuration path. > > >> 2 other behaviours I noticed that I find strange: >> A DELETE request, if not resulting in an error, will always return >> HTTP status 200 and no body content, no matter if a queue with that >> name exists or not A DELETE request, if not resulting in an error, >> will always return HTTP status 200 and no body content, no matter if >> a queue with that name exists or not >> >> I would expect to somehow be notified of the fact that a queue I try >> to delete does not exist or that a queue I try to create already exists. >> > > What was the other behaviour (I presume a cut and paste error above as > (as far as I can tell) the two behaviours above are exactly the same)? Indeed, copy paste error on this, sorry. I observed the behaviour not only for DELETE, but also for PUT. I.e. if I try to create a new queue and use a name of a queue that already exists, e.g. "newQueue", the response sent will have HTTP status 200 and no body content. This means a client has no chance to find out that the queue already existed and was not newly created. So, if queue "newQueue" already existed, let's say configured as not durable and the client sends a PUT request to create queue "newQueue" configured as durable, the not durable queue "newQueue" will just continue to exist. The client can only be aware of this if either the broker is restarted and the queue will have disappeared or by checking the configuration of the queue after having created it. > > I agree that a DELETE that causes change should behave differently to > a DELETE that deletes nothing... we should change that behaviour. > > > -- Rob > > > >> >> >> Best regards, >> Julien >> >> Avitech GmbH >> Engineering AxL >> Tel.: +49 (0)7541/282-177 >> Fax: +49 (0)7541/282-199 >> e-mail: [email protected]<mailto:[email protected]> >> ________________________________________________ >> Avitech GmbH >> Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany >> Court Registration: Amtsgericht Ulm | HRB 728293 >> Geschäftsführer/Managing Director: Jon Joseba Goyarzu Caño >> http://avitech.aero<http://avitech.aero/> >> >> This message may contain confidential information and is intended >> only for the individual named. If you are not the named addressee you >> should not disseminate, distribute or copy this e-mail. Please notify >> the sender immediately by e-mail if you have received this e-mail by >> mistake and delete this e-mail from your system. >> >> >
