FAQ: Chariot MQTT Server

This document provides answers to frequently asked questions about the Chariot® MQTT Server.

Where can I download Chariot?

You will find the latest Chariot downloads here: Chariot® Downloads.

What is the recommended size of a VM or EC2 instance to run Chariot MQTT Server?

The Chariot MQTT Server runs best using a contemporary system with at least 4 CPU cores and 8GB of memory.

I'm upgrading my Chariot server hardware. Does this invalidate my existing license? 

Yes. You will need to temporarily deactivate your license before shutting down the Chariot server pre-upgrade. Next perform the server upgrade. Finally, activate your existing license by re-uploading and reactivating as shown here.

I have MQTT clients failing to connect over TLS/SSL with a "Handshake timeout, no data received" error. Can this SSL handshake timeout be increased?

Yes. Currently this configuration option is not available in the UI. First ensure you're running a Chariot version of 2.1.1 with a build date of 2021 May 13th or later (if not, upgrade). Next add the following line to the <Chariot_Install_Dir>/conf/com.cirruslink.chariot.server.config file.

sslHandshakeTimeout=I"30000"

This sets the timeout to 30000 ms (30 sec). Increase the timeout further if required.

What format of private key must I use?

The Private Key must be a RSA private key of type PKCS1 in PEM format. Review How to identify my Private Key type to verify the type

How to I configure the Chariot max heap size?

The Chariot max heap size is not configured and in prior to V2.2.3 defaulted to 1GB. In V2.2.3 onward the max heap size defaults to 2GB.

The Chariot max heap size can be configured on all version of Chariot in the <chariot_install_dir>/chariot/yajsw/conf/wrapper.conf file.

# Example 4GB Max Heap 2

wrapper.java.additional.6 = -Xmx4g

Note: a Chariot service restart is required for Chariot to pickup the configuration change.

How do I manage log files?

The Chariot wrapper.log text files can be managed on all version of Chariot in the <chariot_install_dir>/chariot/yajsw/conf/wrapper.conf file.

wrapper.logfile.loglevel=INFO

wrapper.logfile=${wrapper_home}/../log/wrapper.log

wrapper.logfile.format=LPDTM

wrapper.logfile.maxsize=10m

wrapper.logfile.maxfiles=10

wrapper.logfile.rollmode=SIZE

wrapper.logfile.maxdays=60

wrapper.logfile.desc=true

Based on this, up to 10 files of 10MB is size each may be retained. However, this isn’t exact and if logging is very verbose these can surpass that size limit and end up being larger.

Note: a Chariot service restart is required for Chariot to pickup the configuration change.

The DB logfile can be managed in the com.cirruslink.chariot.persistence.h2-logging.config file. In this is a config option:

tables.1.maxRows=I"262144"

When maxRows is set, there will actually be two tables of that size created. When one fills up it will truncate the other one, to clear all the data, and then switch to using it rotating between the two tables.

Note: a Chariot service restart is required for Chariot to pickup the configuration change.

Is bridging supported by Chariot?

A Bridge Client allows you to connect Chariot to another MQTT Server to share messages between the two servers. The shared messages can be restricted by topic filters to only share a subset of messages flowing through either of the servers. A common usage is to connect edge MQTT brokers to a central or remote broker. When enabled on Chariot, the Bridge Client becomes an MQTT client to the other MQTT Server. This client publishes messages, flowing through Chariot, to the other broker. It also subscribes on topics with the other broker to receive messages and deliver them to subscribed clients connected to Chariot.

Bridging is supported in version 2.3.0 forward. See the Chariot MQTT Server Configuration guide for details on configuring bridging.