Implementing MQTT QoS using DDS

3 posts / 0 new
Last post
rip
rip's picture
Offline
Last seen: 1 month 4 days ago
Joined: 04/06/2012
Posts: 324
Implementing MQTT QoS using DDS

MQTT provides a "Last Will & Testament" QoS, that causes a writer to emit a final instance when it it shuts down, effectively a shut-down hook.

I want to implement the same thing using DDS {in Java*}.  I'm looking for different ideas on what might be a best-practice...

I want to avoid writing my own manual shutdown algorithm (I want to call <participant>.delete_contained_entities(), and have that trigger a final sample being published).

At the moment I'm subclassing the data writer:

//pseudo
public class FooDataWriterExt extends FooDataWriter {
   FooData shutdownMessage = null;
   InstanceHandle_t sdm_ih = InstanceHandle_t.HANDLE_NIL;
   ...
   public setShutdownMessage (FooData msg) {
      shutdownMessage = msg;
      sdm_ih = super.register_instance(shutdownMessage);
   }
   ...
   public void finalize() {
      super.write(shutdownMessage, sdm_ih);
      try { Thread.Sleep(250); } catch (InterruptedException ie) {};
   }

but I'd like to make <writer>.finalize() something that is called by a <ancestor>.delete_contained_entities(); or <publisher>.delete_datawriter(...); without having to write all that pesky code myself.

Another method I've used is to add infrastructure to the remote participants so that when something is seen to go away, the application is notified.  Being able to send a pre-canned "closing down" message means not having to implement tables of who's attached via the participant's BuiltinTopic detection listener hooks.  this is ... heavy.

Any other implementation suggestions?

* When I've looked at the c or c++ implementations, I haven't see shutdown-hooks.  Or didn't recognize them.

 

Organization:
Keywords:
Gerardo Pardo's picture
Offline
Last seen: 1 month 1 week ago
Joined: 06/02/2010
Posts: 598

Hi Rip,

DDS already sends a "going away message" when a DDS application shuts down gracefully (i.e. you call the DomainParticipantFactory::delete_participant() ).

This is sent via the DomainParticipant discovery to notify other applications that the DomainParticipant (and all its contained entities) is going away. You should be able to get this notification either reading the ParticipantBuiltinTopicData. Would that meet your use-case or do you need to send specific information on that "last will" message?

Gerardo

rip
rip's picture
Offline
Last seen: 1 month 4 days ago
Joined: 04/06/2012
Posts: 324

Hi Gerardo,

I have used the BuiltinTopicData before.  Using the BuiltinTopicData I have to deal with everything that comes and goes.  I would prefer to have available a way to watch for a specific writer's last sample, which may contain application specific information beyond what is available to the metadata (*why* it is going away or what was the last thing it did before an unexpected (polite) shutdown for example).  I would occasionally update the LastSample instance, and then when the Writer is deleted, it spits out the LastSample, pauses, then only allows the deletion to happen once the LastSample is out the queue.

In one sense I'm trying to come up with counter arguments to MQTT usage, by showing how to implement the things that MQTT provides, that DDS doesn't.

Thanks!

r