Hi, We also have problem with misconfigured clients which cause error logs on the server, mostly in test environments. It seems that it has no impact on other clients in our test lab. I don't know how to solve it, but maybe you can try to use some external authentication mechanism (maybe on some external haproxy server or load balancer). There is an example for Keycloak in the ActiveMQ Artemis github, but I don't know if it can solve the problem.
I have configured log rotation to prevent filesystem filling. I used log4j2 RollingFile appender with DefaultRolloverStrategy (limit number of files) and SizeBasedTriggeringPolicy (limit size of one file). If you run broker on Linux, you can also use logrotate. Also you can turn off some logging or configure filters in the log4j2 configuration to filter out some most annoying log messages, but it can impact performance. It is difficult to read logs with lots of client errors, but if you send logs to Opensearch, you can easier search for logs and filter out some events. -- Best regards, Aleksandr -----Original Message----- From: Shiv Kumar Dixit <shivkumardi...@eurofins.com.INVALID> Sent: Monday, August 21, 2023 10:00 AM To: users@activemq.apache.org Subject: RE: Pre-authentication with Broker Hi, Is there any suggestion on this topic? Best Regards, Shiv -----Original Message----- From: Shiv Kumar Dixit <shivkumardi...@eurofins.com.INVALID> Sent: Monday, July 24, 2023 12:01 PM To: users@activemq.apache.org Subject: Pre-authentication with Broker [shivkumardi...@eurofins.com.invalid appears similar to someone who previously sent you email, but may not be that person. Learn why this could be a risk at https://aka.ms/LearnAboutSenderIdentification ] CAUTION: EXTERNAL EMAIL - Sent from an email domain that is not formally trusted by Eurofins. Do not click on links or open attachments unless you recognise the sender and are certain that the content is safe. We would like to know if there is any mechanism to pre-authenticate broker users first (basic authentication or certificate authentication) and if the credentials/certificate is valid then only connection attempt is made on the broker. We are seeing a case where some users are either using invalid user-name password or invalid certificate (expired/missing private key or different cases of SSL handshake failure) to connect to brokers. Since such applications keep running with invalid authentication and take lot of time to fix from client side, we are seeing too many connection attempts being made which subsequently failing on the broker. Broker logs also get filled very fast due to it. We can't just block those erring IP as same IP can host a good and a bad application. Blocking the IP will also block well behaving application. Some broker versions (e.g. 2.27.1) are very sensitive to such errors and it impacted normal broker operations where new good connections were denied or delayed, existing consumers were not able to pull messages or clustering and movement of messages across cluster was impacted. We would like to explore any proxy or pre-authentication where such erring consumers are not allowed to make any connection attempt itself thus safeguarding the broker. Any input or lead will be very useful. Thanks Shiv ----------------------------------- This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient any use, distribution, copying or disclosure is strictly prohibited. If you have received this message in error, please notify the sender immediately either by telephone or by e-mail and delete this message and any attachment from your system. Correspondence via e-mail is for information purposes only. AO Raiffeisenbank neither makes nor accepts legally binding statements by e-mail unless otherwise agreed. -----------------------------------
