This is not specific to authentication, and allows plugins greater flexibility in what events they are interested in. It also adds message handling, and $CONTROL handling.
In some circumstances, Mosquitto could leak memory when handling PUBLISH messages. This is limited to incoming QoS 2 messages, and is related to the combination of the broker having persistence enabled, a clean session=false client, which was connected prior to the broker restarting, then has reconnected and has now sent messages at a sufficiently high rate that the incoming queue at the broker has filled up and hence messages are being dropped. This is more likely to have an effect where max_queued_messages is a small value. This has now been fixed.
Closes#1793. Thanks to mbates14.
If we have e.g. max_inflight_messages set to 1000, and currently have 999 messages inflight, then when we send a new message to a client we have to iterate over the whole list to get to the newest message. This change means that we start of the back of the list to find the newest items, which reduces overhead.
Signed-off-by: Brandt Hill <brandtlarsonhill@gmail.com>
Change variable name for clarity. Remember to initialize bool (I'm bad at C).
Signed-off-by: Brandt Hill <brandtlarsonhill@gmail.com>
Add documentation to config man page
Signed-off-by: Brandt Hill <brandtlarsonhill@gmail.com>
Add test case for deny option
Signed-off-by: Brandt Hill <brandtlarsonhill@gmail.com>
Add deny acls to top of the list to preserve early exit
Signed-off-by: Brandt Hill <brandtlarsonhill@gmail.com>
change comments
Signed-off-by: Brandt Hill <brandtlarsonhill@gmail.com>
New messages are now queued for clients when old ones are sent, rather than on every iteration of the main loop. This produces good performance improvements.
Rename mosquitto_plugin_publish() to mosquitto_broker_publish().
These two functions achieve the same thing. *_publish() publishes the payload and frees it later. *_publish_copy() takes a copy of the payload, so the plugin still owns the memory it passed to the function.
In the mux_epoll__add_in function, no context->events was set. Previously this was set to match the ev.events (EPOLLIN). Adding this back in, keeps the code consistent to before it was refactored to split out epoll and poll functions, as well as being consistent with the other mux_epoll__ functions.
If this is not set, the connection is never fully established when the broker comes back up.
Fixes#1680.
Signed-off-by: Simon Tate <simon.tate@bt.com>
From the FormatMessage() Win32 API documentation: "The lpBuffer
parameter is a pointer to an LPTSTR; you must cast the pointer
to an LPTSTR (for example, (LPTSTR)&lpBuffer)."
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage#parameters
This commit fixes warnings like these:
warning C4047: 'function': 'LPSTR' differs in levels of indirection from 'char **'
warning C4024: 'FormatMessageA': different types for formal and actual parameter 5
Signed-off-by: Sigmund Vik <sigmund_vik@yahoo.com>
This fixes Visual Studio compiler warnings like this one:
"warning C4003: not enough arguments for function-like
macro invocation 'G_MSGS_DROPPED_INC'"
Signed-off-by: Sigmund Vik <sigmund_vik@yahoo.com>
Before this commit there was no good way to detect that the
Mosquitto broker was done with its startup phase on systems
without systemd.
On such systems it was tricky to e.g. start the broker from
a test where ports are dynamically assigned and one have to
deal with potential port conflicts. Without a way to know
that the broker is done with its startup phase, there was no
way to know if the broker was able to acquire the port (for
both IPv4 and IPv6) without waiting for some unknown period
of time (when many tests are run in parallel a single process
might be starved for resources).
With this new broker ready message it is easy for the parent
process to monitor the broker output and figure out when the
port was successfully acquired.
Signed-off-by: Sigmund Vik <sigmund_vik@yahoo.com>