LogoLogo
2.1.0
2.1.0
  • Welcome
  • Getting Started
  • Downloads
  • VerneMQ / MQTT Introduction
  • Installing VerneMQ
    • Installing on Debian and Ubuntu
    • Installing on CentOS and RHEL
    • Running VerneMQ using Docker
  • Configuring VerneMQ
    • Introduction
    • The VerneMQ conf file
    • Schema Files
    • Auth using files
    • Auth using a database
    • MQTT Options
    • MQTT Listeners
    • HTTP Listeners
    • Non-standard MQTT options
    • Websockets
    • Logging
    • Consumer session balancing
    • Plugins
    • Shared subscriptions
    • Advanced Options
    • Storage
    • MQTT Bridge
    • REST Publisher
  • VerneMQ Clustering
    • Introduction
    • Inter-node Communication
    • Dealing with Netsplits
  • Live Administration
    • Introduction
    • Inspecting and managing sessions
    • Retained messages
    • Live reconfiguration
    • Managing Listeners
    • Certificate Management
    • HTTP API
    • Tracing
    • Output Format
  • Monitoring
    • Introduction
    • $SYSTree
    • Graphite
    • Netdata
    • Prometheus
    • Health Checker
    • Status Page
  • Plugin Development
    • Introduction
    • Session lifecycle
    • Subscribe Flow
    • Publish Flow
    • Enhanced Auth Flow
    • Erlang Boilerplate
    • Lua Scripting Support
    • Webhooks
  • Misc
    • Loadtesting VerneMQ
    • Not a tuning guide
    • Change Open File Limits
  • Guides
    • A typical VerneMQ deployment
    • VerneMQ on Kubernetes
    • Loadtesting VerneMQ
    • Clustering during development
    • Not a tuning guide
    • Change Open File Limits
    • Migrating to 2.0
Powered by GitBook
On this page
  • Retry Interval
  • Inflight Messages
  • Load Shedding

Was this helpful?

Edit on GitHub
Export as PDF
  1. Configuring VerneMQ

MQTT Options

Configure how VerneMQ handles certain aspects of MQTT

Retry Interval

Set the time in seconds after a QoS=1 or QoS=2 message has been sent that VerneMQ will wait before retrying when no response is received.

retry_interval = 20

This option default to 20 seconds.

Inflight Messages

This option defines the maximum number of QoS 1 or 2 messages that can be in the process of being transmitted simultaneously.

max_inflight_messages = 20

Defaults to 20 messages, use 0 for no limit. The inflight window serves as a protection for sessions, on the incoming side.

Load Shedding

The maximum number of messages to hold in the queue above those messages that are currently in flight. Defaults to 1000. Set to -1 for no limit. This option protects a client session from overload by dropping messages (of any QoS).

max_online_messages = 1000

Defaults to 1000 messages, use -1 for no limit. This parameter was named max_queued_messages in 0.10.*. Note that 0 will totally block message delivery from any queue!

This option specifies the maximum number of QoS 1 and 2 messages to hold in the offline queue.

max_offline_messages = 1000

Defaults to 1000 messages, use -1 for no limit, use 0 if no messages should be stored.

In contrast to the session based inflight window, max_online_messages and max_offline_messages serves as a protection of queues, on the outgoing side.

override_max_online_messages = off

When an offline session transits to online, by default VerneMQ will adhere to the queue sizes also for moving data from the offline queue to the online queue. Therefore, if max_offline_messages > max_online_message VerneMQ will start dropping messages. It is possible to override this behaviour and allow VerneMQ to move all messages from the offline queue to the online queue. The queue will then batched (or streamed) to the subscribers, and the messages are read from disk in batches as well. The additional memory needed thus is just the amount needed to store references to those messages and not the messages themselves.

PreviousAuth using a databaseNextMQTT Listeners

Last updated 20 days ago

Was this helpful?