Jump to content
OpenSplice DDS Forum
Emmanuel Prunet

Multitopic in isocpp2

Recommended Posts

Hi

I'm new at Opensplice DDS and I was wondering if there was any way to create a listener of a Topic corresponding to a join ( like in SQL) of multiple Topics.

From what I saw Multitopics are the solution but they don't seems to be implemented in Opensplice DDS

Share this post


Link to post
Share on other sites

Hi Emmanuel,

 

You're right in that MultiTopics are indeed targeting that functionality and also in your observation that this functionality isn't supported yet (actually by none of the current DDS-vendors).

The reason behind not having implemented this (yet) is that there are still gaps in the semantics in case of incomplete information in 2 situations:

(1) when should you first get a joined-set (i.e. only when its complete w.r.t. availability of all the attributes from all topics that you're interested in

(2) when should you last get updates on a joined-set (i.e. up to the point where at least one of the attributes has reached the end of its lifecycle e.g. is part of a disposed instance)

 

That said, its not rocket-science to do such a joint on application-level (as we ARE following a relational model isn't it) .. and apply some basic semantics for the above ..

 

We're still looking at some good (business-)cases that would justify investment in that piece of missing spec-coverage so perhaps you can contribute yours :)

Share this post


Link to post
Share on other sites

Hi Hans and thank you for your quick response. I'll explain why we need MultiTopic.

 

We have a conceptual model where we have a lot of inheritance, to simplify let's say we have :

A( k , a ) 

B( b )

C( c )

where k is primary key and B and C inherits from A. In our case B and C are exclusive , but at runtime a B can become a C and a C can become a B but A can't exist by itself.

 

From this conceptual model we can create topics like this :

 

1) A( k , a , b  , c ) => not acceptable in our case because it will allocate too much memory

 

2) A( k , a ) , B( k , b ) , C( k , c ) => this solution seemed to be the best for us, but a lot of issues arise : When do we notify a new B exists? That's why we need a multitopic that joins A and B and notify a new instance exists only if this instance exist in A and B. But even if I implement myself a multitopic, since we have a lot of inheritance, I'll have a multitopic on ( A , B ) , a multitopic on ( A , C ), and a lot more of multitopics that needs to observe A, meaning that I'll have a LOT of readers on A (and also a lot of readers on B and C because in our case they are inherited themselves by D,E, F etc...). Is that efficient to have this much readers on the same topic? Do they share the same cache? Is there a way to have multiple listeners on the same reader?

Another issues is this : what if an instance of B arrives but the corresponding instance of A never arrives? Is there a way in DDS to say "I'm going to write an instance on A and B but the readers needs to receive A and B or none" (sounds like a transaction in SQL). Also is there a way to say "I'm going to write A and B and the readers will receive A THEN B in that order" ?

 

3) B( k, a, b )  , C( k , a , c ) => this solution is more simpler because when we receive notification from B and C we know that A already exists ( A is in B and C ), so there is no need of multitopics. But when B become a C, we must destroy an instance of B and create one of C, and that's not exactly what we want, solution 2) is more flexible for that. Also, we want to listen to A B and C individually, in solution 3) we must listen to B and C to listen to A.

 

The solution i'm thinking about is mixing 2) and 3) : creating a topic for B (k, a, b )  and C(k, a, c) for instanciation and deletion of B and C, and topics A( k , a ) , B( k , b ) , C( k , c ) for updates of A B and C.

Do your IDLParser supports Unions? A single Topic for  B( k, a, b )  and C( k, a, c) would be great ( BC ( k , a , { b , c } ) ) , because I will not destroy a A to create a C from a B.

Share this post


Link to post
Share on other sites

Yes, our IDLParser(s) do support unions. What languages do you envision ?

 

I'll start some discussions internally on the above and see what we could do to help in the short-term as proper multi-topic support isn't on the horizon yet.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×