ActiveMQ is used in Blackboard Learn as an asynchronous message queue service to provide a distributed, fault-tolerant mechanism for sending messages between load-balance application servers to be processed in the background of the application. ActiveMQ is bundled in Learn and is automatically installed when Learn is installed.
ActiveMQ installs with the default communications port 61616. All application servers within the given installation must have the same communication port open. If this port is not open, the servers are not able to connect to the ActiveMQ broker. This causes some application functions (for example, manual integration feeds through the user interface or command-line) to work incorrectly.
Changing the ActiveMQ Default Communications Port
If the default communications port for ActiveMQ is not compatible with your installation, you may change it. Change the communications port by editing bbconfig.messagequeue.transport.port in the bb-config.properties file. If you change the port on one application server, you must make the same change on all application servers within the given installation. To learn more, see bb-config.properties File.
Resolving Host Names
Each application server must be able to resolve the unique hostname configured by the other application servers to communicate with them. This host name is configured in
bbconfig.appserver.fullhostname in the
bb-config.properties file. To learn more, see bb-config.properties File.
Hosts much be reachable not only on the ActiveMQ port, but they must also communicate on a non-configurable, randomly assigned port for proper cache notification. Ensure that ports 1024 and higher are open for inter-node communication over TCP. Otherwise, cached data updates will take effect only on other servers, and there will be a significant delay (cache timeout period).
Events related to this message queue are appended to the tomcat log files.
The logs for Service Pack 9 and above:
The logs for Service Pack 8 and older:
How to Configure ActiveMQ
- To enable checksum and journal corruption checks, edit blackboard/config/message-queue-service-config.xml.bb by replacing:
<kahaPersistence directory="activemq/messageQueueService/kaha" checksumJournalFiles="true" checkForCorruptJournalFiles="true" />
- If you want to use manual peer discovery instead of multicast peer discovery, change the client configuration so that the brokerURL parameter includes the peers directly, where yourapplicationserver# is the application server URL and 61616 is the ActiveMQ communications port:
<!-- Configuration for client -->
<client brokerURL="failover:nio://yourapplicationserver1:61616,nio://yourapplicationserver2:61616,nio://yourapplicationserver3:61616" useAsyncSend="true" optimizeAcknowledge="true" optimizedMessageDispatch="true" dispatchAsync="true" copyMessageOnSend="false" disableTimeStampsByDefault="true" initConnections="5" maxIdleConnections="5" retryCount="5"/>
- Update the transport connector URI so that the broker will listen on all interfaces, where and 61616 is the ActiveMQ communications port:
<!-- In a multi-appserver environment, only one appserver's broker will have transports open and will be in charge of dispatching all messages. The others will wait and fail-over as necessary. The messages themselves will be load-balanced over all of the consumers (on different appservers) --> <transportConnector name="openwire" uri="nio://0.0.0.0:61616?keepAlive=true" /> </transportConnectors>
How to Verify ActiveMQ Database Tables
- Open up the latest application logs:
- Verify that they do not contain error entries indicating ActiveMQ datastore corruption, such as:
org.apache.kahadb.journal.Journal - Corrupt journal records found
- If corruption is evident, proceed with the following steps.
- Stop services on all application servers.
- Remove (or rename) the blackboard/content/vi/bb_bb60/activemq folder to trigger the recreation of ActiveMQ's tablespaces.
- Start services on all application servers.