Re: [mosquitto-dev] A mosquitto's design suboptimization case in our use

[Roger Light <roger@xxxxxxxxxx>]

Hi Felipe,

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.

Cheers,

Roger



On Tue, Nov 3, 2015 at 5:59 PM, Felipe Lavratti <felipelav@xxxxxxxxx> wrote:
> Hello!
>
> 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
> degradation.
>
> What do you guys think of that?
>
>
>
> --
> Skype: felipeanl
>
>
> _______________________________________________
> mosquitto-dev mailing list
> mosquitto-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/mosquitto-dev