qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ken Giusti (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-4174) QMF events for (dis)connecting a client to have few more parameters
Date Fri, 31 Aug 2012 18:09:11 GMT

    [ https://issues.apache.org/jira/browse/QPID-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446189#comment-13446189

Ken Giusti commented on QPID-4174:

Hi Pavel,

This is a great suggestion.   I was thinking a bit about it and wondered if it would be more
flexible to include the entire "client properties" map in the events rather than just the
three properties mentioned above.

What do you think?  Right now, the QPID clients put the pid, ppid, and command name into the
"client-properties" map.  In theory, a non-QPID 0.10 client can put anything they'd like into
it - so there's really no guarantee that pid, ppid, and command name *have* to be there. 
(see the description of the connection.start-ok command in the 0.10 spec).

In AMQP 1.0, the Connection Open frame has an equivalent field for connection properties,
which, I assume, would serve the same role for 1.0-based clients (see the description of the
Open frame in the Performative section of the AMQP-1.0 spec)

So, the argument list of the QMF events above would instead be something like this:

  <arg name="clientProperties" type="map"   desc="A map containing optional information
about the remote client"/>

  <event name="clientConnect"     sev="inform" args="rhost, user, clientProperties"/>
  <event name="clientConnectFail" sev="warn"   args="rhost, user, reason, clientProperties"/>
  <event name="clientDisconnect"  sev="inform" args="rhost, user, clientProperties"/>

And the pid, ppid, and command name could be accessed via the clientProperties map using the
keys "qpid.client_pid", "qpid.client_ppid", and "qpid.client_process", respectively.

The benefit of this approach is that it allows us to add new properties in the future without
having to write additional QMF code to support them.   The downside is that the management
app would have to index the map manually.

Just a consideration - what do you think?

> QMF events for (dis)connecting a client to have few more parameters
> -------------------------------------------------------------------
>                 Key: QPID-4174
>                 URL: https://issues.apache.org/jira/browse/QPID-4174
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Qpid Managment Framework
>    Affects Versions: 0.14
>            Reporter: Pavel Moravec
>            Assignee: Ken Giusti
>            Priority: Minor
>              Labels: patch
>         Attachments: 0001-connect-event-more-QMF-parameters
> I suggest enhancing values populated in 3 events relevant for client (dis)connection:
> clientConnect
> clientConnectFail
> clientDisconnect
> For these events, I suggest adding values:
> remoteParentPid
> remotePid
> remoteProcessName
> That is useful for various reasons:
> 1) To have better information who just disconnected or failed to connect (i.e. better
monitoring allowing to easily identify the process that is e.g. failing to connect repeatedly)
> 2) To allow client processes (listening for the events) to easily know the disconnect
event is relevant to itself by comparing its PID with remotePid.
> I am attaching a patch for it.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message