Log crate instead of println

[flxo]

We're using this broker in a proof of concept and would like to replace the println! logs with the log crate macros. I can push a PR but want tot clarify first if this is something mergeable. I would replace and the println! calls with debug!, info!... and initialise env_logger(?) in the main.

@bschwind fine for you?

[bschwind]

Hey @flxo , cool to hear that you're using this as a proof of concept! I've been using it a bit at home for some ESP32 boards but that puts essentially no load on the broker. I'd be curious to hear how your real-world usage goes with it.

I'm totally fine with replacing the println! calls with macros from the log crate. Thanks for contributing!

[flxo]

Thanks for your fast reply.

Hey @flxo , cool to hear that you're using this as a proof of concept! I've been using it a bit at home for some ESP32 boards but that puts essentially no load on the broker. I'd be curious to hear how your real-world usage goes with it.

Our use case is a single (no replication) broker distributing QoS1 publications as efficiently as possible. Clients are connected via loopback only. Furthermore we need some custom "behaviour" upon connects and subscriptions. There's no explicit API for that in mqtt-broker but it's so damn simple...

[bschwind]

distributing QoS1 publications as efficiently as possible

Do you find this binary is working out for you in that regard? I'm aiming for efficiency, but I can't really say I've put any effort yet into making things as fast as possible. But if it's already working well for your use case, that's good to hear!

I hear you about custom behavior for MQTT events, looking forward to figuring that out in #44

[flxo]

distributing QoS1 publications as efficiently as possible

Do you find this binary is working out for you in that regard?

The missing retains are a show stopper for now. But there's #41

I'm aiming for efficiency, but I can't really say I've put any effort yet into making things as fast as possible. But if it's already working well for your use case, that's good to hear!

The performance lineary decreases with the number of connected clients in a simple QOS1 thourghput test. I will try to describe the test more in detail and provide a link to the setup. We compared mqtt-broker with rumqttd, mosquitto and HiveMQ (quite an odd round ;-))

I hear you about custom behavior for MQTT events, looking forward to figuring that out in #44

Think the plugin topic is larger. Let's try to just do the lib bin split in #44 .

I think there's not the one golden way to add custom behaviour into a broker instance. This could be done by passing a trait impl or closure or message passing etc. No idea wha't best. I'll try to open a dedicated ticket for that. At least for the authentication such a mechanism is needed in order to fully implement MQTT5 (auth).