Remove unkeyed Topic?

5 posts / 0 new
Last post
Offline
Last seen: 3 years 11 months ago
Joined: 08/25/2015
Posts: 32
Remove unkeyed Topic?

Hi,

is it possible to remove an unkeyed topic from DDS? The only way I found so far is to remove the corresponding DataWriter. But that's not really an option I guess...

Or is it possible to dynamically add a (dummy) key to a given topic?

 

Thx,

Christian

gianpiero's picture
Offline
Last seen: 2 months 1 week ago
Joined: 06/02/2010
Posts: 177

Hello Christian,

I am not sure I understand what are you trying to do.. to remove a topic you have to be sure that no object are using the topic. Here what the documentation says: 

Make sure no objects are using the topic. More specifically, there must be no existing DDS_DataReaderDDS_DataWriterDDS_ContentFilteredTopic, orDDS_MultiTopic objects belonging to the same DDS_DomainParticipant that are using the DDS_Topic. If delete_topic is called on a DDS_Topic with any of these existing objects attached to it, it will fail with DDS_RETCODE_PRECONDITION_NOT_MET.

 

You can find the full API doc here

If you delete a topic is because you are not interested anymore in participanting to that 'conversation'... hence why keeping the DataWriter? 

I hope this help, let me know

Best,
  Gianpiero

Offline
Last seen: 3 years 11 months ago
Joined: 08/25/2015
Posts: 32

I try to implement a simple request/reply pattern with the modern c++ api.

A client sends a topic and later receives the answer from the server. To not get answers for others, I create a datawriter with a content filter topic which is checking the writer_guid from the related sample id.

This is all fine until the server process gets restartet - since the writer is still alive, the server gets the (already handled) message again which is not what I want.

So if I delete the writer, I also have to recreate the reader (since I somehow can't modify the filter string later on with the modern c++ api, don't know if this works with other apis). This is possible but I don't know anything about the costs - I assume that it's creating a lot of traffic on dds when a new reader and writer is created.

Offline
Last seen: 2 months 2 weeks ago
Joined: 04/02/2013
Posts: 194

Hi Christian,

Are you using transient-local durability QoS? If you use volatile, the DataReader on your server side shouldn't receive the messages again.

Our latest release (5.2.3) does support modifying the content filter (see this). In previous releases you could only modify the expression parameters, but not the expression itself.

Also, are you aware of the Request-Reply API that RTI provides? It pretty much handles what the kind of filtering you're doing. However we still don't have a modern C++ version of that API, which we are working on for the next major release.

Alex

 

Offline
Last seen: 3 years 11 months ago
Joined: 08/25/2015
Posts: 32

Hi,

we were using the Request-Reply API from RTI for our initial work with 5.1. Then we switched over to 5.2 and modern C++. Since there was no request-reply API, we decied to implement our own on top of the modern C++ API (it's very limited but does what we need) but stay as close as possible on the given Request-Reply API so we maybe have a chance to replace this with your work in 5.3.

Therefore I studied what's sent between your requester and replier and did the same for our replacement.That's the reason why I searched a way to not remove the datawriter/datareader from the requester - it's not done in your Request-Reply lib either (and also the QoS is no transient-local in your requester afaics). But what I missed was the test if the behaviour with the resend sample when the replier is restart is the same with your lib.

I'll maybe use transient-local as this sounds more like what we need - a (internal) timeout when the replier is not available and no later resubmit when the replier comes on again.

 

Thx,

Christian