I am using failover protocol with static discovery, along with TransportListerner for transfer/failover detection.
There is an onCommand() method. I understand this method delivers transport info and on consumer side is used to count messages received.
Are there some typical usage beyond these? I can hardly find any document on it. I am thinking to pump in some command to brokers/clients. Is it possible?
> Hi guys.
> I am using failover protocol with static discovery, along with
> TransportListerner for transfer/failover detection.
> There is an onCommand() method. I understand this method delivers transport
> info and on consumer side is used to count messages received.
> Are there some typical usage beyond these? I can hardly find any document on
> it. I am thinking to pump in some command to brokers/clients. Is it
> View this message in context: http://activemq.2283324.n4.nabble.com/TransportListerner-onCommand-tp4680911.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
As you know, I am using broker network + failover for DR. I use transportListerner such that I can get some info when failover happens. I can understand transportResumed, onException stuff, but have no idea why onCommand is there.
What's it supposed to do? Anything I need to take care of after messages 'unmarshalled off the wire'?
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.