ActiveMQ warning messages in Bamboo Server log

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Summary

Bamboo server logs show ActiveMQ warning messages in Bamboo Server log;

WARN [ActiveMQ BrokerService[bamboo] Task-130] [TransportConnector$1] Could not accept connection from tcp://127.0.0.1:39452: Connection or outbound has closed (Connection or outbound has closed). 
...
WARN [ActiveMQ NIO Worker 9] [Transport] Transport Connection to: tcp://127.0.0.1:45384 failed: closing inbound before receiving peer's close_notify
...
WARN [ActiveMQ BrokerService[bamboo] Task-6] [TransportConnector$1] Could not accept connection from tcp://127.0.0.1:52294: Remote host terminated the handshake (SSL peer shut down incorrectly)

Cause

As part of a remote agent startup process, Bamboo Server Broker URL is tested for validity.

INFO   | jvm 1    | 2023/07/04 16:10:10 | 2023-07-04 16:10:10,343 INFO [AgentRunnerThread] [BambooActiveMQConnectionFactory] Broker URI: ssl://ip-192-168-1-89.us-west-2.compute.internal:54663?socket.verifyHostName=false&wireFormat.maxInactivityDuration=300000 is valid.

The remote agent closes the connection immediately after the test, this fact that the socket connection was closed by the agent side of the connection causes ActiveMq to raise the exception seen as a warning in Bamboo log.

Solution

As a workaround, add custom Log4J entries on the Bamboo server by changing the default WARN log level to ERROR on the following classes:

  • org.apache.activemq.broker.TransportConnector
  • org.apache.activemq.broker.TransportConnection

It is recommended to add the entries to the <Bamboo-Install>/atlassian-bamboo/WEB-INF/classes/log4j2.properties file so the custom configuration can survive an application restart.

Reducing the Log4j logging level for certain classes may mask legitimate warning messages that could be used to identify a real problem. Use it with caution.

A final solution for this problem is currently being tracked by this bug BAM-22413 - Getting issue details... STATUS .

Last modified on Feb 25, 2024

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.