Hi Sven,
Thanks, now I understand better the use of QoS and session ID with a
practical use case.
How do you deal with the lifetime of each "listener" (subscriber) on
each image? I mean, how stable is it?
E.g.
MQTTClient new
open;
subscribeToTopic: '/updates';
runWith: [ :message |
Transcript cr; show: '[UPDATED]'; space; show: message contents
asString; cr.
];
yourself.
You just fork that and it will continue to receive messages until you
close the connection? Is there a watchdog class/library to ensure
things like this continue working? (I'm used to having my images
living for months sometimes).
Thanks in advance.
Regards!
Esteban A. Maringolo
On Wed, Jun 30, 2021 at 5:00 AM Sven Van Caekenberghe <s...@stfx.eu> wrote:
>
>
>
> > On 30 Jun 2021, at 01:28, Esteban Maringolo <emaring...@gmail.com> wrote:
> >
> > I like the Ansible approach using RabbitMQ, in particular because it
> > would also work to delegate tasks to workers (even if in the same
> > image), and the task queue would be preserved, whilst in MQTT if there
> > are no subscribers for a topic, then all messages sent to it are
> > discarded.
>
> That is correct but less of a problem in practice than it seems to be at
> first sight.
>
> As a client, you normally have to be able to start from scratch and load
> everything that came before the moment you start up.
>
> When a client with a specific ID has connected once with clean session false,
> QoS 1 and a subscription, the persistence of the queue will be enabled for a
> as long as the server lives (and maybe even beyond restarts).
>
> There is absolutely no question that Rabbit MQ has much more functionality, I
> found Mosquitto MQTT very nice to work with, but as always, YMMV.
>
> Sven
