Each component simply sets the "product" and "version" entries into
its connection properties map, which use a map with amqp symbol keys,
e.g Symbol.valueOf("product"); in the case of proton-j.

For example, the JMS client does it here:


On 5 April 2016 at 18:22, Garlapati Sreeram Kumar <sreer...@live.com> wrote:
> Can you please point me to those Symbols. I would love to not re-invent & 
> reuse those …
> Thx!
> Sree
> From: Robbie Gemmell<mailto:robbie.gemm...@gmail.com>
> Sent: Tuesday, April 5, 2016 10:14 AM
> To: proton@qpid.apache.org<mailto:proton@qpid.apache.org>
> Subject: Re: Amqp-ConnProp: user-agent
> Many of the Qpid components advertise "product" and "version"
> connection properties containing strings with the appropriate details.
> Those [Symbol] keys were chosen because they happened to be names
> specified in the older AMQP 0-x specs, and so matched what some of the
> components were already using.
> Robbie
> On 5 April 2016 at 18:02, Garlapati Sreeram Kumar <sreer...@live.com> wrote:
>> Hello Folks!
>> In our (Microsoft Azure EventHubs) java library, we are looking for a way to 
>> identify which AmqpClient did the call originate from.
>> We want to use this information to:
>> 1) Identify client stack while troubleshooting Service issues - for ex: a 
>> bug in implementation of AmqpProtocol stack
>> 2) collect telemetry on how many different clients are talking to our 
>> service (which will open-up data insights in future, for ex: investing our 
>> efforts on the right client echo system etc.,)
>> To achieve this - we are planning to introduce a Property (on AmqpConnection 
>> -  [AMQP-CONNPROP]) to identify UserAgent.
>> - We chose “Connection properties” – as this would be one-time per 
>> connection and will not add extra overhead per message.
>> I believe this would be a common requirement to all Amqp implementations. 
>> Are you folks aware of any proposal to add a standard property to Amqp 
>> Protocol Specification (or) is there already one that you folks use for this 
>> purpose – in any of the Clients – which we can re-use and collectively 
>> propose to the protocol spec.
>> Thanks a lot for the Wonderful collaboration!
>> Sree

Reply via email to