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.
In addition to data integration, other areas that rely on ActiveMQ include:
- Blackboard Collaborate
- Date management
- Item analysis
- Building blocks
- Course copy, archive, and restore operations
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.
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 save your changes you must update the configuration by running the PushConfigUpdates command. This action restarts services.
Since this change must be made on all appservers at the same time, use your scheduled maintenance window and not a rolling restart.
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.
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:
- 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, including the collab-server and any stand alone JVMs such as the snapshot tool, batch archive, and background system tasks.
Remove (or rename) the /content/vi/bb_bb60/activemq/messageQueueService/kaha folder to trigger the recreation of ActiveMQ's tablespaces.
- Start services on all application servers.
In the Blackboard Learn 9.1 Q2 2016 release, ActiveMQ uses a new implementation to improve the overall reliability of the service and increase memory allocation to the broker.
The three implementations are:
- KahaDB File-based persistence
- Blocking JDBC-based locking
- Lease-based JDBC locking
Some of the implementations are included in base releases, but other implementations may require configuration or patches. Refer to the table below.
|October 2014||Q4 2015||Q2 2016|
|KahaDB persistence||Included in base release||Included in base release||Not recommended|
|Blocking-based persistence||Patch & configuration needed||Included in base release, configuration needed||Not recommended|
|Lease-based persistence||Patch & configuration needed||Patch & configuration needed||Included in base release|
More information about setting up lease-based JDBC persistence for ActiveMQ can be found on Behind the Blackboard.
Logs can be found here:
Additional logs, listed below, are present in the Q2 2016 release and later.