Using Persistence service with Request-Reply communication Pattern

2 posts / 0 new
Last post
Last seen: 9 years 10 months ago
Joined: 07/29/2014
Posts: 1
Using Persistence service with Request-Reply communication Pattern


I am trying to build an application based on the request-reply communication pattern and using the RTI Persistence service.

The request and the reply topics are same.

The request is getting persisted in the MySQL Database but the application is not receiving the reply.

I am using the receive_reply() API while waiting for replies.

Attached is a screenshot of the data contained in the tables.

Thanks And Regards


Image icon Screen shot of the data99.92 KB
Gerardo Pardo's picture
Last seen: 1 week 1 day ago
Joined: 06/02/2010
Posts: 602

Hello Vivek,

Can you clarify a couple of things?

1. What do you mean by saying that "the request and the reply topics are same" normally these two topics have to have different names. Do you mean you only specify a "service name" so that the system chooses them for you or are you using the constructor that explicltly sets the topic names and setting both request and reply topics names to be the same?  I do not think the latter would work at all since they are typically different data-types...

2. What behavior are you expecting from persisting the request/reply?

Normally PersistenceService is used so a late joiner can see the data that was sent while the consumer application was not there. So are you expectiong to be able to issue a request, then have the requesting application go away, then re-start the requester later and get the reply to the earlier request? Or are you expecting a different application alltogether see the reply to a request done by a different requeter application?

I think neither of the above two will work. This is because replies are directed back to the requester that sent them. So if you re-start the application or have a different application it will not have the same Requester GUID and hence not receive the replies to earlier requests. 

However since the replier containd underneath a regular DDS DataWriter on the reply Topic I think you could create a DataReader directly (wihout using the Requester) to see that reply. All you have to do us use the proper Topic name and Type and set the QoS to have DURABILITY Qos policy TRANSIENT or PERSISTENT (as well as RELIABILITY). The reson this can work and not the Requester is that each Requester automatically installs a content filter in the DataReader used for replies to filter out replies to requests not sent by that same Requester.