qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Detecting presence of AMQP-MANAGEMENT server capability from the Qpid JMS Client
Date Fri, 02 Dec 2016 17:36:27 GMT
On 2 December 2016 at 17:13, Robbie Gemmell <robbie.gemmell@gmail.com>

> Yes, there wont currently be a way to do this, thus far the
> capabilities have only ever been used for things the client itself
> acts upon. Also, for any extended behaviour present thus far we have
> only used e.g vendor properties and such like within the existing API,
> and have resisted adding additional APIs beyond those provided by JMS.
> I'm not sure there is a facility we could use here for such things
> though, one to think about.
The only way I can think to expose this is via defining a format for the
JMSProviderName in the ConnectionMetaData that serializes the offered
capabilities and server side defined connection properties in some way.  If
this was standardised then one could parse the version string to find out
the necessary information.

As you point out this doesn't seem to be necessary for amqp management
(since the detection of $management" should be enough presuming you are not
talking to a service which auto-creates destinations...  But other
properties/capabilities might affect how your application functions.

Of much more interest to me (particularly in the use of AMQP management) is
the ability set properties on Destinations (through JNDI would suffice,
though also having a String format for Sessin.createQueue would be
better).  In particular being able to control the local source/target
address (and possibly in future the link name).  The "direct" request
response model requires that the client creates an receiving link with a
given target address (and a source address of $management)... the reply-to
on messages sent to $management is then that target address on the
consumer.  Currently there is no way to achieve this with the JMS client :-(

-- Rob

> For now, given you are presumably talking about the Qpid Java broker
> here....can you simply try opening the link and have it fail if not
> supported? I'd guess if you try to attach to the management address,
> since it doesnt automatically create entities by default it would have
> to refuse the link instead?
> Robbie
> On 2 December 2016 at 15:39, Keith W <keith.wall@gmail.com> wrote:
> > Hi,
> >
> > In QPID-7556, we intend to advertise the Qpid Broker for Java AMQP
> > Management ability with an AMQP 1.0 open performative
> > offered-capability [1] of 'AMQP-MANAGEMENT'.
> >
> > As a user of the Qpid JMS Client, how do I detect that the server
> > offers this capability?
> >
> > At the moment, from what I see of the public API, I don't have a way
> > to check for an arbitrary server offered-capabilities.
> > AmqpConnectionProperties cherry picks the capabilities that are
> > currently known/interesting but there is no way to check for an
> > arbitrary one.
> >
> > AmqpConnectionProperties could be simply changed to detect the
> > AMQP-MANAGEMENT (isAmpqManagementSupported()), or it could offer an
> > API to the user could enquire on a particular capability.
> >
> > My use case is test automation.  I need check whether I can use AMQP
> > Management so I may fallback back to an older management technique,
> > but, I believe the feature would have general utility.
> >
> > cheers Keith.
> >
> >
> > [1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-
> transport-v1.0-os.html#type-open
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message