activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arthur Naseef (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-3876) WireTap of TransportConnector messages for diagnostic purposes
Date Thu, 14 Jun 2012 16:14:54 GMT

    [ 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

        

Mime
View raw message