> On 1 Jul 2021, at 20:58, Esteban Maringolo <emaring...@gmail.com> wrote:
>
> 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?
Basically, yes.
> Is there a watchdog class/library to ensure
> things like this continue working? (I'm used to having my images
> living for months sometimes).
I have an MQTTListener class that wraps the MQTT client and its process, the
process's run method looks like this:
run
[
self log: 'Starting MQTT reading'.
self ensureMQTTClient ifTrue: [
mqttClient runWith: [ :message |
self handleMessage: message ] ].
self log: 'End of MQTT reading, restarting in 5s'.
self closeMQTTClient.
5 seconds wait ] repeat
It is a bit crude but it does help to restore the connection when the broker
becomes temporarily unavailable.
> 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
