qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: Detecting presence of AMQP-MANAGEMENT server capability from the Qpid JMS Client
Date Mon, 05 Dec 2016 12:38:37 GMT
On 2 December 2016 at 18:29, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
> On 2 December 2016 at 19:03, Robbie Gemmell <robbie.gemmell@gmail.com>
> wrote:
>
>> On 2 December 2016 at 17:36, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
>> > On 2 December 2016 at 17:13, Robbie Gemmell <robbie.gemmell@gmail.com>
>> > wrote:
>> >
>> >> 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.
>> >
>>
>> At first thought it feels like that might be a stretch too far :)
>>
>
> Yeah - I didn't say I *liked* the thought... but other than horribly
> abusing JMSX properties in some way, that seemed like the only way to get
> information about the connection in a "standardized" way.
>
>
>>
>> > 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
>> >
>>
>> Indeed, we currently have no system in place for per-destination
>> manipulations of the AMQP link details like that, only some bits
>> around prefetch/settlement/redelivery etc.
>>
>>
> Yeah - as far as implementing some upcoming AMQP standards, I think that
> will become an issue... not sure where the best forum to discuss it is
> though..
>
> -- Rob
>
>

I think these would be discussed here at Qpid as implementation
details before qualifying for discussion in other forums.

>> >
>> >> 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
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message