VerneMQ
  • Welcome
  • Getting Started
  • MQTT Introduction
  • Installing VerneMQ
    • Running VerneMQ using Docker
  • Configuring VerneMQ
    • Introduction
    • The VerneMQ conf file
    • Auth using files
    • Auth using a database
    • Enhanced Auth
    • MQTT Options
    • MQTT Listeners
    • HTTP Listeners
    • Non-standard MQTT options
    • Websockets
    • Logging
    • Consumer session balancing
    • Plugins
    • Shared subscriptions
    • Advanced Options
    • Storage
    • No Op Engine
    • Generic offline store
    • Redis based message passing
    • Redis based subscription store
    • MQTT Bridge
  • VerneMQ Clustering
    • Introduction
    • Inter-node Communication
    • Dealing with Netsplits
  • Live Administration
    • Introduction
    • Inspecting and managing sessions
    • Retained messages
    • Live reconfiguration
    • Managing Listeners
    • HTTP API
    • Tracing
  • 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
    • Events sidecar Plugin
  • 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
Powered by GitBook
On this page
  1. Configuring VerneMQ

No Op Engine

Configure how VerneMQ implements message persistence

generic_message_store_engine=vmq_storage_engine_no_op

This implementation of message store does not persist messages to the disk.

Tradeoffs

When a node in a VerneMQ cluster restarts, it tries to load from the disk, all it's messages before it was shutdown. We have seen that this process is very CPU intensive and time-taking, and it may so happen that the node may not be able to join the cluster.

This config allows the node to restart and join the cluster because it does not have to build it's messages from the disk. The drawback is that all the messages that were not synced with other nodes before the node got killed will be lost.

PreviousStorageNextGeneric offline store

Last updated 2 years ago