You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Jonathan Robie <jo...@redhat.com> on 2007/06/21 19:51:19 UTC
createQueue() method (in Java)
Here's the signature for createQueue():
createQueue(final AMQShortString name, final boolean autoDelete, final
boolean durable,
final boolean exclusive) throws AMQException
Why an AMQShortString for the name - wouldn't a Java string be simpler?
Should we provide different signatures for this method, providing
defaults for some of the arguments?
Jonathan
Re: createQueue() method (in Java)
Posted by Robert Godfrey <ro...@gmail.com>.
As an aside, I would argue that for a low level API, AMQShortString
would be the correct type for the argument to a declareQueue method,
as the valid set of names for a queue is not (java.lang.)String but
only (a subset of) those that can be represented by AMQShortString.
(Obviously higher level APIs (such as JMS) will offer String as the
type, but we need a well defined encoding to convert these into
AMQShortString representation).
-- Rob
On 22/06/07, Rupert Smith <ru...@googlemail.com> wrote:
> Also, perf test suite should really have been coded to the JMS api only.
> Something I intend to change eventually...
>
> On 22/06/07, Martin Ritchie <ri...@apache.org> wrote:
> >
> > This method is only used from the performance test suite as a
> > convenience for creating a queue. We have never made attempts to
> > expose the underlying AMQP as an API. If we were to do such a thing
> > then a lang.String would of course be the natural choice. Currently
> > all Strings in the client API that are sent across the network are
> > AMQShortStrings. This was a change made to aid performance. Continued
> > conversion between String and the Short String format for the wire was
> > quite an overhead in the Java client.
> >
> > I would suggest that we put the put an item on the agenda for the Java
> > F2F to discuss an AMQP API but as there are a lot of things that are
> > changing with the protocol perhaps the best thing to do is if you find
> > the createQueue method useful but would rather have a String method
> > then create one that does the AMQShortString wrapping for you (Most of
> > the other JMS API/Public calls do something similar). When the 0_10
> > AMQP is released then I'm sure we can address any API mapping we wish
> > to do.
> >
> > On 21/06/07, Jonathan Robie <jo...@redhat.com> wrote:
> > > Here's the signature for createQueue():
> > >
> > > createQueue(final AMQShortString name, final boolean autoDelete, final
> > > boolean durable,
> > > final boolean exclusive) throws AMQException
> > >
> > > Why an AMQShortString for the name - wouldn't a Java string be simpler?
> > >
> > > Should we provide different signatures for this method, providing
> > > defaults for some of the arguments?
> > >
> > > Jonathan
> > >
> >
> >
> > --
> > Martin Ritchie
> >
>
Re: createQueue() method (in Java)
Posted by Rupert Smith <ru...@googlemail.com>.
Also, perf test suite should really have been coded to the JMS api only.
Something I intend to change eventually...
On 22/06/07, Martin Ritchie <ri...@apache.org> wrote:
>
> This method is only used from the performance test suite as a
> convenience for creating a queue. We have never made attempts to
> expose the underlying AMQP as an API. If we were to do such a thing
> then a lang.String would of course be the natural choice. Currently
> all Strings in the client API that are sent across the network are
> AMQShortStrings. This was a change made to aid performance. Continued
> conversion between String and the Short String format for the wire was
> quite an overhead in the Java client.
>
> I would suggest that we put the put an item on the agenda for the Java
> F2F to discuss an AMQP API but as there are a lot of things that are
> changing with the protocol perhaps the best thing to do is if you find
> the createQueue method useful but would rather have a String method
> then create one that does the AMQShortString wrapping for you (Most of
> the other JMS API/Public calls do something similar). When the 0_10
> AMQP is released then I'm sure we can address any API mapping we wish
> to do.
>
> On 21/06/07, Jonathan Robie <jo...@redhat.com> wrote:
> > Here's the signature for createQueue():
> >
> > createQueue(final AMQShortString name, final boolean autoDelete, final
> > boolean durable,
> > final boolean exclusive) throws AMQException
> >
> > Why an AMQShortString for the name - wouldn't a Java string be simpler?
> >
> > Should we provide different signatures for this method, providing
> > defaults for some of the arguments?
> >
> > Jonathan
> >
>
>
> --
> Martin Ritchie
>
Re: createQueue() method (in Java)
Posted by Martin Ritchie <ri...@apache.org>.
This method is only used from the performance test suite as a
convenience for creating a queue. We have never made attempts to
expose the underlying AMQP as an API. If we were to do such a thing
then a lang.String would of course be the natural choice. Currently
all Strings in the client API that are sent across the network are
AMQShortStrings. This was a change made to aid performance. Continued
conversion between String and the Short String format for the wire was
quite an overhead in the Java client.
I would suggest that we put the put an item on the agenda for the Java
F2F to discuss an AMQP API but as there are a lot of things that are
changing with the protocol perhaps the best thing to do is if you find
the createQueue method useful but would rather have a String method
then create one that does the AMQShortString wrapping for you (Most of
the other JMS API/Public calls do something similar). When the 0_10
AMQP is released then I'm sure we can address any API mapping we wish
to do.
On 21/06/07, Jonathan Robie <jo...@redhat.com> wrote:
> Here's the signature for createQueue():
>
> createQueue(final AMQShortString name, final boolean autoDelete, final
> boolean durable,
> final boolean exclusive) throws AMQException
>
> Why an AMQShortString for the name - wouldn't a Java string be simpler?
>
> Should we provide different signatures for this method, providing
> defaults for some of the arguments?
>
> Jonathan
>
--
Martin Ritchie