That method, onCommand(), is called for every transport "command"; commands are the unit of the ActiveMQ openwire protocol (not sure what happens with non-openwire). So, it is called with tremendous detail that is very highly activemq-internal-specific. And it is called with high frequency on busy connections.
With a short look through the ActiveMQ code, it's possible to see that onCommand() is actually used in ActiveMQ's TransportConnection - the key class in ActiveMQ's termination of the connection from clients. That's where all handling of the protocol occurs for a connection. The idea of injecting commands to the transportListener makes me nervous - what would be the reason to inject commands at that level rather than using the client API designed to carefully encapsulate those details? One thing to consider there is that changes to ActiveMQ internals have a high likelihood of breaking any such code. Another consideration is that mistakes in injected commands can lead to challenging problems to diagnose. My recommendation for a TransportListener is to leave onCommand() alone and only use the onException(), transportInterrupted(), and transportResumed() methods. -- View this message in context: http://activemq.2283324.n4.nabble.com/TransportListerner-onCommand-tp4680911p4680979.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
