[
https://issues.apache.org/jira/browse/QPID-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13929816#comment-13929816
]
Chuck Rolke commented on QPID-5619:
-----------------------------------
Some time ago this request came up. Instead of logging/tracing individual
messages we added information for object life cycles. See
https://reviews.apache.org/r/5616/diff/5/.
The request at time time was for logging messages as they pass through the
system as you are suggesting. When I looked at that I couldn't see how to do it
without clobbering system performance (checking potentially long user and queue
name lists on a per message basis; at many places) or creating too much
coupling between modules (knowing the user name from a connection when
delivering messages through any exchange). Every time I started coding a
solution I had to add args to various functions to expose the logging-test
information and it got cumbersome very quickly.
Your proposal includes many considerations. What would be the minimum subset,
do you think, that would still deliver useful tracing functionality?
.
> [C++ broker] Add message auditing
> ---------------------------------
>
> Key: QPID-5619
> URL: https://issues.apache.org/jira/browse/QPID-5619
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Broker
> Affects Versions: 0.24
> Reporter: Pavel Moravec
> Labels: features
>
> There is a reasonable request to have message enqueue/dequeue audited. It can
> help troubleshooting or monitoring situations when the broker is suspected
> from discarding a message that was sent to it but never received by a
> consumer.
> Implementation options as to be discussed in qpid users mailing list:
> 1) Key feature:
> a) where to store/send the information about new message enqueue/dequeue?
> - store it in a configurable log-file (per queue? per broker?) - problem
> with format of binary data there
> - amend/modify replicated queues for this purpose - though replicated
> queues are designed not to replicate messages that are dequeued before they
> have been replicated
> - generate QMF event to be sent to
> "qmf.default.topic/agent.ind.event.org_apache_qpid_broker.<queue_name>.audit.<enqueue|dequeue>"
> topic - note this would have to change qpid.subject to route the message
> properly
> - have dedicated audit exchange for this purpose (of topic type, I expect)
> - again, qpid.subject would have to be changed
> b) how to trigger message auditing:
> - via QueueObserver (thanks Gordon for idea)
> 2) Options of auditing:
> a) audit enqueue+dequeue events only? or also acquire, release, reject?
> b) it should be possible to track only one from enqueue | dequeue |
> acquire events, or all of them
> c) event/message should contain:
> - timestamp
> - original message (or just its header? or configurable?)
> - type of event (enqueue/dequeue/..)
> - identification of consumer acquiring/dequeueing the message (and also
> producer?)
> 3) Provisioning/managing auditing:
> a) have the possibility to turn on/off auditing per queue (via QMF)
> b) have some x-declare arguments for the auditing when declaring the queue?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
