|Re: [mosquitto-dev] A mosquitto's design suboptimization case in our use|
The bridge connection should be non-blocking - with the exception that
it uses getaddrinfo for lookups, which will block in the case that the
DNS isn't available. I imagine that this is where problems are being
introduced for you. You could test this by setting a IP address
instead of a host name for your bridge connection.
Workarounds could be setting a low timeout on your DNS lookups or
installing a local caching DNS server.
The real solution is of course to use asynchronous DNS lookups which
is something that will be implemented in a future version.
On Tue, Nov 3, 2015 at 5:59 PM, Felipe Lavratti <felipelav@xxxxxxxxx> wrote:
> I'd like to share a design sub-optimization issue related to the Mosquitto
> broker implementation pattern where no parallelism is used, and ask for any
> opinions and insights about it.
> We run the mosquitto broker inside a network node that plays the central (or
> coordinator) role of the given network. Every systems protocols runs on top
> of the MQTT and uses the central node and this network is self contained, it
> doesn't need external internet access to proper operate.
> The Mosquitto broker running in the central node have a bridge connection to
> a remote broker for low priority data transfer.
> What I see as an issue, in our use case, is that under very poor internet
> connection, the bridge takes considerable long time to connect (and
> sometimes it never connects) turning the broker unresponsive during this
> period, which will bring all local and high priority services to
> What do you guys think of that?
> Skype: felipeanl
> mosquitto-dev mailing list
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
mosquitto-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top