Synchronous call with solace new java api

For the asked questions:

1) can we secure the topic using ACLS?

Yes ACLs should work on direct subscriptions.

If not how to do it with Queues ?

Should not be needed but if they still want to... RequestReplyPublisher and Receivers only support direct messaging not persistent messaging. It is possible to construct the request reply pattern using the existing persistent publisher and receivers. However then the application handle the method of correlationID (setting the existing public correlation id) and reply to destination via the custom properties as the replyTo destination is not publicly accessible. This might not be cross api compatible unless the applications handle the customer properties.

2) how are concurrent requests handled in request-reply? will there be a case where if there are 2 concurrent requests Req1 and Req2,
but,
Req1 recieves Res2
Req2 recieves Res1

This might be entering implementation details but publishAwaitResponse will block until the the first response that has the matching correlationId. You can get multiple responses with multiple repliers thought his is not the case they have presented. Each call to publish/publisherAwaitResponse should set a unique correlation id + replyTo topic combination (implementations may have unique correlation ids in general). This should mean each Replier.reply call replies to a unique publish call from a requestor message. Note if you have multiple calls to Replier.reply in the receiver only the first to reach the publish call waiter is presented to the request reply callback the rest are discarded. On timeout all responses for the request are discarded.As per the ordering all request reply publisher push out messages in order of the call to publish/publishAwaitResponse. So long as the network has a single path to the receiver/replier from the request reply publisher its reasonable to expect the following:

pub req1 with corrId-p1-1
recv/replier receives req1 with corrId-p1-1 sends res1 for corrId-p1-1
pub req2 with corrId-p1-2
recv/replier receives req2 with corrId-p1-2 sends res2 for corrId-p1-2 

To have concurrent request with publishAwaitResponse you need multiple thread for a single publisher or multiple publishers. In which case the order of pub req1 and pub req2 is not deterministic and the receiver/replier will receive the req1 in the network order they were sent in. And the publisher can expect to receive its first matching reply response unique its request message.I guess the above is to say once you start adding multiple publishers/threads or multiple receivers/replier ordering of requests and response might not be synchronized. The api does not enforce ordering for responses but does match requests response to the first reply response where the order is receiver/replier dependent. Where you can get the following with two publisher and one receiver/replier:

pub2 req2 with corrId-p2-1
pub1 req1 with corrId-p1-1
recv/replier receives req2 with corrId-p2-1 sends res1 for corrId-p2-1
recv/replier receives req1 with corrId-p1-1 sends res2 for corrId-p1-1
pub2 receives res1 for corrId-p2-1 
pub1 receives res2 for corrId-p1-1