Hej Jakub, This is entirely possible if you start your implementation as a regular BrokerPlugin (talking here about AMQ 5.x APIs). I’ve seen such implementations and even participated in one and they did work nicely. What is tricky is eventual loop detection of internal connections, even one which forwards advisory somewhere else, which you will most likely see. You can use AdvisoryBroker as a starting point and change it to something what you need.
Your sincerely, Łukasz Dywicki > On 21 Jan 2020, at 17:36, Jędrzej Dudkiewicz <jedrzej.dudkiew...@gmail.com> > wrote: > > Hello, > > I've seen some questions regarding connection state monitoring, but > they all (from what I've seen) are based on advisory topic. My > question is: > > if I wrote a plugin that would be executed for all connections, would > it be able to hijack each and every connection event and send > information regarding this fact to some queue that I'll select? I'm > asking not whether there is interface for it (there is), but whether > there is a chance that I would miss some events - most probably this > will be during broker startup or shutdown, so I'm most interested in > this area. I wrote test plugin and it seems to work, but maybe there > is a chance that I will enter a state where I won't be able to send to > queue (as this part of broker will be not ready yet or will be already > closed). > > Note that I'm not interested in any same-jvm connections or internal > amq connections, only external (TLS) connections. > > Any pitfalls that you know of? > > Thanks in advance, > -- > Jędrzej Dudkiewicz > > I really hate this damn machine, I wish that they would sell it. > It never does just what I want, but only what I tell it.
