New mechanism to tweak/query transport plugins via Admin API #2354
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a new synchronous Admin API request, called
query_transport
, that allows you to communicate with a transport plugin, like for instancequery_eventhandler
andquery_logger
already did for event handlers and loggers. The idea was to allow both dynamic configurations of transports (e.g., change settings) and queries on their internal state, where applicable. As with the other plugin categories that already supported something like this, it's an optional callback, meaning that your custom transport doesn't need to implement it: you'll need to recompile it, though, since the transport plugin API version has been bumped.At the moment only very simple requests have been implemented: specifically, all transport plugins allow you to change the value of
events
andjson
you specified in the configuration files on the fly; the WebSocket transport also allows you to change thelibwebsockets
logging level; finally, some plugins also allow you to query the number of active connections (e.g., HTTP, WS, Unix Sockets). That's because this PR is, again, just opening the door to this new mechanism, and I didn't want to overdo it: I'm sure in the future we can add more meaningful tweaks, but for the time being everything else seemed to be more complex that this effort called for, so I went for the low hanging fruit instead.For a couple of examples, this is the request you can send to the HTTP transport to get the number of active connections and the number of messages currently being served, and the response sent back by Janus:
while this is how you can change some of the settings (notice how the transport adds a note to say it handled the request, but won't be used since event handlers are globally disabled):
Planning to merge soon, so feedback welcome.