OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [amqp] AMQP standard connection properties for process, pid etc


On Mon, Oct 22, 2018 at 5:13 PM Rob Godfrey <rgodfrey@redhat.com> wrote:
>
> Do we want anything to capture the (logical) application name/version (separate from the product/library name and version), which would likely be very distinct in the case of "clients"?  Do you expect "process name" to be the literal name of the process as understood by the host operating system (e.g. would 90% of all java programs report "java" here?)

Firstly my reason for process_name's existence to to help an Operator
by corroborating a PID.   I am imaging  a case where a messaging app
has gone wild and operator intervention is required.  Humans easily
make mistakes with numerics so by making the process_name and
process_id together I hope to reduce this chance.  For this,  the
process_name would be a best efforts capture the name of the program
as it would appear on the process table.

The practicalities of the population of process_name will vary by
implementation language.  Python and NodeJS make an argv available
(with different semantics).  For Java, the cmd line is available from
Java 9 onwards (ProcessHandle).  It would be nice if the process_name
could capture the name of the interpreter/runtime (if any) plus the
name of the program's entry point, but this might to code without
introducing fragility.  IIRC, in Java, there remains no pure mechanism
to find the name of the Main class that the JVM started.  All of this
would be implementation concern,

Implementations would need to take care to avoid exposing the whole
command line, as it is possible a careless application might pass a
secret to it that way.

I am not sure see the value of making the (logical) application
name/version known to the messaging layer.    I see this as part of
inventory management and a separate concern to messaging.

>
> -- Rob
>
> On Mon, 22 Oct 2018 at 17:45, Keith Wall <kwall@redhat.com> wrote:
>>
>> All,
>>
>> I'd like to restart the discussion about identifying a standard set of
>> AMQP connection properties that would allow an AMQP container to
>> communicate to its peer information about itself and its execution
>> environment.
>>
>> The use-case for this information is two fold:
>>
>> - to aid troubleshooting expose process identifier/process name, and
>> - to assist configuration management expose the names/version of the
>> product providing the AMQP implementation.
>>
>> These data-items are particularly valuable for large organisation
>> where complex messaging systems comprising hundreds or thousands of
>> applications are common place.   In such organisations, positivity
>> identifying an errant application or an application using an out of
>> date library can be challenging: revealing this information in a
>> standard way helps.
>>
>> The use of these connection properties by an AMQP implementation would
>> not be mandatory.  However, standardising the names and value types
>> will encourage interoperability.
>>
>> The intention would be to produce AMQP TC Committee Note capturing the
>> standardised connection properties.
>>
>> My proposal, which builds on previous work [1], is for four connection
>> properties.
>>
>> (1) process_name, which can be used to convey the name of the process
>> associated with the connection
>>
>> (2) process_id, which can be used to convey the PID of that same process.
>>
>> (3) product, which can be used to provide the name of the product
>> providing the AMQP implementation.
>>
>> (4) version, which can be used to provide the version information of
>> the product named by 3).
>>
>> Comments welcome,
>>
>> Keith Wall.
>> [1] https://markmail.org/thread/omv7kb3zqycxo7zf
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
>
> --
> _____________________________________________________________________________
>
> Red Hat GmbH, www.de.redhat.com,
> Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]