Thank you very much for the possible solutions. I finally was able to try the approach with the interceptor and it works great for intercepting messages send to the broker using SessionSendMessage to filter the messages I want to intercept.
Unfortunately, it does not intercept messages sent from the broker to the message driven bean. I configured the interceptor to intercept incoming and outgoing messages and it only “catches” the following types. Ping ClusterTopologyChangeMessage_V4 CreateSessionMessage_V2 CreateSessionResponseMessage SessionAddMetaDataMessageV2 NullResponseMessage_V2 PacketImpl SessionQueueQueryMessage SessionQueueQueryResponseMessage_V3 SessionBindingQueryResponseMessage_V4 SessionQueueQueryResponseMessage_V3 SessionRequestProducerCreditsMessage SessionSendMessage_V2 NullResponseMessage_V2 SessionCloseMessage The SessionReceiveMessage used in the examples is never found. Could that be a problem with the resource connector? Currently we are still using the activemq-rar-5.16.3 resource adapter because I was not able to find an artemis version. Or does the incoming interceptor only work when using a MessageConsumer? Thank you very much for helping me with those options I am not sure if I would have found them on my own in a timely manner. Best regards Hannes On 2021/10/26 12:32:24 Tim Bain wrote: > The success of that approach would depend on how OP's clients are > interacting with the broker. > > If all producers are OpenWire connect and stay connected forever with no > disconnects and no producers coming and going, then this manual process > could work. If producers come and go (including due to auto-scaling or > producer process instability or restarting the broker), or if they produce > messages by making a new connection each time (including if messages are > produced via STOMP, which I believe is always connectionless), it won't. > > If you need to be sure it works in the face of any of the things I listed, > I'd continue to recommend implementing this as a plugin. If you're sure you > have a stable environment, or if best-effort is good enough, then the JMX > approach sounds possible. > > Tim > > If you need to be sure this works co > > On Tue, Oct 26, 2021, 2:39 AM Simon Lundström <si...@su.se> wrote: > > > Isn't it also possible to stop the client connector via JMX? > > > > org.apache.activemq:type=Broker,brokerName=esb-test-mq04.it.su.se,connector=clientConnectors,connectorName=ssl > > > > has a stop operation. > > > > Does this not work the way OP intends? > > > > Pause queue(s), stop connector(s). No messages in or out? > > > > BR, > > - Simon > > > > On Fri, 2021-10-22 at 04:42:18 +0200, Tim Bain wrote: > > >I believe it would be possible to write a custom interceptor (see > > https://activemq.apache.org/interceptors) that rejected incoming messages > > and incoming connections. (Maybe rejecting incoming connections would be > > enough, because you can't send a message without an established > > connection.) If you restart the broker when you apply it, that should give > > you what you need. > > > > > >Alternatively, you could put a reverse proxy such as Nginx in front of > > the broker, and then modify its configuration to disable/re-enable the > > OpenWire port. Then JMX and web console connections could go through but > > protocol connections would be stopped. > > > > > >Tim > > > > > >On Thu, Oct 21, 2021, 2:47 AM Bauer, Hannes <h...@tangro.de<mailto: > > h...@tangro.de>> wrote: > > >Hello, > > >I am working on an application that is using ActiveMQ 5.16.3 and I am > > tasked with implementing a feature that should pause the whole message > > process. > > > > > >In the application we have producers and message driven beans as > > consumers. The goal is to stop the consumption of messages as well as the > > acceptance of new messages in the queues. > > >At first, I was hoping that pausing a queue would do exactly that, but I > > quickly learned that that only stops messages from being delivered. > > >And now I need an option to also prevent queues from accepting new > > messages. > > > > > >What I am trying to achieve in the end is somewhat like this existing > > thread > > > > > https://lists.apache.org/thread.html/r615e1b6c2cdf6341ac69935f24190a865147b32e3b95dfb35c86383e%40%3Cusers.activemq.apache.org%3E > > >But the proposed solution with multiple brokers and a failover is not > > applicable/feasible in our use case. > > > > > >So far, the only other option I found is to stop the complete broker by > > stopping the windows service. > > >But this obviously creates new challenges since we can no longer get > > information on the size of the queues for example. > > > > > >Is there another way to stop the consumption and creation of messages? > > >Ideally with an instant exception when a sent is attempted on a queue > > that is stopped? > > > > > >Any help/hints are greatly appreciated > > > > > >Regards > > >Hannes > > > > > > [cid:tangro-logo-cyan-rgb_cc8f5a9b-fee1-495e-878a-457c4b170988.png] > > > > > >Hannes Bauer > > >Entwicklung > > >h...@tangro.de<ma...@tangro.de> > > >Fon +49 6221 1333 666 > > >www.tangro.de<http://www.tangro.de> > > > > > > <https://www.linkedin.com/company/3731516/> > > [cid:linkedin_cyan_Flche_c8d1d8e0-819d-446d-a928-19e3f92da84a.png] < > > https://www.linkedin.com/company/3731516/> > > [cid:xing_cyan_Flche(1)_3aa617c4-0f52-4b4f-9e00-9fac40d37193.png] < > > https://www.xing.com/companies/tangrosoftwarecomponentsgmbh> > > [cid:youtube_cyan_Flche_bbde269b-c7da-48df-b3a9-3ec7dfe09432.png] < > > https://www.youtube.com/channel/UCsxrvLKxYpQ-KYK8uGQ8tVQ> > > [cid:Twitter-Icon_cyan-Flche_14719373-0a07-425c-88a4-31303fb01996.png] < > > https://twitter.com/tangro_software> > > [cid:tangro_newsletter_icon_rgb57-176-201_139x42_7758a315-d1ec-4829-adce-36eea7130bda.gif] > > <https://www.tangro.de/newsletter/> <https://www.tangro.de/newsletter/> > > > > > >tangro software components gmbh, Speyerer Straße 4, 69115 Heidelberg > > >Geschäftsführer: Andreas Schumann, Registergericht: Mannheim, HRB 336064 > > (Sitz: Heidelberg) > > > > > >
