[
https://issues.apache.org/jira/browse/AMQ-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295134#comment-13295134
]
Arthur Naseef commented on AMQ-3876:
------------------------------------
I've had trouble in the past configuring transport tracing, and was never able
to set it up dynamically.
Can you walk me through how to use the Transport tracing to address the
following scenario (which we just recently had in production)?
- NMS Client reports that they are not receiving messages
- Via VisualVM, we found the Subscription has increasing Enqueue and Dequeue
counts
- Now we want to tap that connection to see just what is "crossing the wire"
I am concerned about the complexity of configuring loggers, but I admit there's
much there with which I am not knowledgable. Such as remote loggers. Only
yesterday did I learn how to dynamically change logger levels via the log4j
MBean.
One big consideration is keeping this tracing separate from other log activity
to both (a) keep from generating large volumes of noise in the normal logs and
(b) to keep the tracing easy to read.
(BTW - I'm an old UNIX/C developer at heart. This prototype is modeled on
truss/strace/tcpdump)
> WireTap of TransportConnector messages for diagnostic purposes
> --------------------------------------------------------------
>
> Key: AMQ-3876
> URL: https://issues.apache.org/jira/browse/AMQ-3876
> Project: ActiveMQ
> Issue Type: New Feature
> Reporter: Arthur Naseef
> Priority: Minor
> Attachments: WireTap.java, WiretapPrototype1.patch
>
>
> Being able to tap into the flow of messages on a TransportConnection would
> greatly help with diagnosing problems such as complaints from clients that
> they are not receiving messages.
> Think "tcpdump" for broker traffic.
> A rough, working prototype will be attached.
> The idea in the prototype is a new Connector on the BrokerService which does
> the following:
> * accepts connections from a wire-tap tool (application)
> * accepts a request to tap a specific TransportConnection
> * adds a tap to the TransportConnection (requires change to
> TransportConnection)
> * sends a copy of every command sent over the connection, via the {{oneway}}
> call, to the tap
> After posting the prototype, I'll post wish-list items.
> If someone with more knowledge and background working with connectors can
> pick this up, that would be great. Otherwise, I'll plan to implement it,
> looking for any advice. For example, one concern is that the tap should
> prefer to drop content rather than either (a) use large amounts of resources
> to buffer them, or (b) in any way impacting the normal flow on the
> TransportConnection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
