The fundamental purpose of messaging platforms is for asynchronous communication. The power is in providing a framework in which data can be published/consumed without end-to-end synchronization or connections. This lends itself well to things like sensor data, published into the broker, where the publisher doesn’t care if none, one, or multiple consumers process the information. This is the core of a publisher/subscriber model, some application publishes, other applications consume. The applications are unaware of each other.
That said, there is still occasionally a need for end-to-end communication and for that the request-reply model exists. It is expected this would be the exception rather than the norm. If you are developing a solution where synchronized communication is required end to end you might be better off looking at some other archiecture such as server/client with raw sockets.
Time-to-live, when set on a published message, allows the Solace broker to ‘expire’ and remove persistent messages that are not consumed. This is an house cleaning operation and affects persistent messages but it is not signaled back to the publisher, so won’t help your use case.
Request-reply: allows the publisher to block and wait for a reply. But your consuming application has to be written to send te reply when it is done. As has been said, this exists to solve end-to-end synchronization in a messaging system and may be suitable for you here.
Condition variables are an advanced synchronization mechanism in many operating systems. They are not a part of messaging and the sample code in OS.h and OS.c merely shows one way you can define a common C interface to condition variables in a portable way so the code that uses them doesn’t have to be rewritten for every target platform. These are not part of the Solace API, they are simply abstractions for a tool that might be used by advanced developers. As none of the Solace examples use this code, it will probably be removed from the samples in a future release.
As the Solace request-reply interface is synchronous and blocking, there is no need for your application to use a condition variable at all.