Baetyl-hub Configuration
Last Updated:2020-08-18
By default, the module reads configuration files from the etc/baetyl directory, and the configuration file format is interpreted as follows:
listen: [Must] Monitoring address, for example:
- tcp:In the //0.0.0.0:1883 # Native progress mode, if you do not want to expose to the device rather than the host machine, it may be changed into tcp://127.0.0.1:1883.
- ssl://0.0.0.0:1884
- ws://:8080/mqtt
- wss://:8884/mqtt
certificate:SSL/TLS certificate authentication configuration item, which must be configured if ssl or wss is started.
ca: CA certificate path of Server
key: Server-side private key path of Server
cert: Server-side public key path of Server
principals:Access to permission configuration item. Client cannot access to it if without configuration, and account password and certificate authentication is supported.
- username: User name of Client connection Hub
password: Password of Client connection Hub
permissions:
- action: Operation permission. pub: Publishing permissions; sub: Subscription permissions.
permit: Subject list allowed by operation permissions, and + and # match signs supported.
- username: User name of Client access to Hub; and no password may be configured when certificate two-way authentication is used.
permissions:
- action: Operation permission. pub: Publishing permissions; sub: Subscription permissions.
permit: Subject list allowed by operation permissions, and + and # match signs supported.
subscriptions: Subject routing configuration item
- source:
topic: Subject subscribed
qos: QoS subscribed
target:
topic: Subject published
qos: QoS published
message: Message-related configuration items
length:
max: Default value: 32k; Maximum value: 268,435,455 bytes (about 256MB), allowable maximum length of message to transmit.
ingress: Message receiving configuration item
qos0:
buffer:
size: Default value: 10000, The number of messages with QoS= 0 that can be cached to the memory. Increase of catch can improve the performance of message receiving. In case of power failure of device, the messages with QoS= 0 will be directly discarded.
qos1:
buffer:
size: Default value: 100, Cache size of messages with QoS=1 waiting for data persistence. Increase of catch can improve the performance of message receiving, however, the potential risk is that the cached messages are lost in case of abnormal Hub exit (for example, device power failure), and puback can be caused. Normal Hub exit can wait for the completion of cached messages handling, without any loss of data,
batch:
max: Default value: 50, Maximum number of messages with QoS=1 written to the database (persistence) in bulk, and acknowledgement by reply after successful message persistence (ack)
cleanup:
retention: Default value: 48h, Storage time of messages with QoS=1 in the database. The messages beyond the storage time are physically deleted upon clearing.
interval: Default value: 1m, Clearing time interval of messages with QoS=1
egress: Message sending configuration item
qos0:
buffer:
size: Default value: 10000, Number of messages with QoS=0 waiting for sending in the memory cache. The messages are lost directly in case of power failure of device; when the cache is full, the newly pushed messages are discarded directly.
qos1:
buffer:
size: Default value: 100, The unacknowledged (ack) message cache size after the messages with QoS=1 is sent. When the cache is fill, new messages are not be read, and it is required to wait for the acknowledgement of messages in the cache. Wait for client validation (pback) after the messages with QoS=1 is sent to the client successfully; in case of no client reply for validation, the messages are resent until the client reply for validation or closing of session.
batch:
max: Default value: 50, Maximum number of messages read from the database in bulk
retry:
interval: Default value: 20s, Re-messaging time interval
offset:Message sequence number persistence-related configuration
buffer:
size: Default value: 10000, Cache queue size of the acknowledged (ack) message sequence number For example, three messages with QoS=1 (sequence numbers 1,2 and 3) are sent to the client in bulk, and after acknowledgment of messages with sequence numbers 1 and 3 in client, the sequence number 1 will queue up and be persisted, however, sequence number 3 can queue up only after acknowledge of sequence number 2 although it is already acknowledged. Such design can ensure that the message handling still can be resumed from the persistence sequence number after abnormal Hub restart, therefore, guaranteeing no loss of messages, however, re-messaging may be caused, therefore, the messages with QoS=2 are not supported temporarily.
batch:
max: Default value: 100, Maximum number of message sequence numbers read to the database in bulk
logger: Log configuration item
path: It is empty by default, i.e., no file is printed; if a file is appointed, it will be output to file.
level: Default value: Info, log level, supporting debug, info, warn and error.
format: Default value: Text, log print format, supporting text and json
age:
max: Default value: 15, Maximum number of days a log file is retained
size:
max: Default value: 50, Log file size limit, unit MB
backup:
max: Default value: 15, Maximum number of log files retained
status:Hub status configuration item.
logging:
enable: Default value: false, Printing of Hub status message or not
interval: Default value: 1m, Status message printing time interval
storage: Database storage configuration item.
dir: Default value: var/db/openedge/data, Database storage directory
shutdown: Hub exit configuration item.
timeout: Default value: 10m, Hub exit time-out period.