We discussed much of this last year already, the situation hasn't changed any since then.
Initial summary points here, then more comments inline below. - Providing a CompletionListener is an explicit request that the send be asynchronous, thats the only reason for providing it. - The '"jms.forceSyncSend' etc URI options are for controlling send calls not using a CompletionListener, and were present from before the client ever supported JMS 2.0 (when CompletionListener support was added and reliable async sends became possible) to govern certain cases it can send asynchronously (see later). - If you use a CompletionListener, the send response will come via the CompletionListener. This is mandated by JMS, and logical since that is precisely what it exists to facilitate (see also next point). - If you want a reliable send result to come via the send method return, then you are implicitly saying that you do not want the send to be asynchronous at all, but rather synchronous, and thus also that you do not want to use a CompletionListener. - Even when you do use a CompletionListener, the send method can still throw an exception, since there is work required to send the message which can fail before the point that happens and responsibility passes to the CompletionListener callback. If send doesnt throw, the result is then notified via the CompletionListener. As with last year, you seem to want async sends to behave exactly the same as sync sends do, but they dont as they are different. You need to decide which approach you actually need/want, synchronous or reliable async, and use or handle it accordingly. I hope it is clear that they will perform essentially the same if all you do is simply send one message and await its response before doing anything else. Robbie On Mon, 10 Jun 2019 at 15:09, akabhishek1 <[email protected]> wrote: > > Hi Robbie, > > Thank you so much for quick response. However, we have couple of open > questions related with Qpid. If you provide us input that will be too great. > We are using "qpid-jms-client-0.40.0" and sending message to Azure Service > Bus. > > 1. Condition - if "jms.forceSyncSend=true" + send(Message message, > CompletionListener completionListener); > Q- Is message will process in SYNC or ASYNC? As i am using > "jms.forceSyncSend=true", so could we get response in CompletionListener or > in same thread? > > I have done testing locally with "qpid-jms-client-0.40.0" and i am > getting response in CompletionListener-onCompletion/onException. > > As per Qpid documentation, "jms.forceSyncSend" should override all > asynchronous send conditions, > But it is not doing at this moment because i am getting response back > with CompletionListener . Is this BUG?? > It is not a bug. As explained above and last year, that option does not control CompletionListener-using sends. Providing a CompletionListener means it is asynchronous and you get the eventual result back via it. That is explicit in its operation and is the only reason for providing it. > > 2. Condition - if "jms.forceAsyncSend=false" + Send with NO > CompletionListener, > Q -Could you please confirm, in this scenario QPID will send message in > SYNC or ASYNC? > This is the same as the default. Persistent messages will be sent synchronously, except inside a transaction. Non-persistent messages will be sent asynchronously. > 2. Condition - if "jms.forceSyncSend=false" + Send with NO > CompletionListener, > Q -Could you please confirm, in this scenario QPID will send message in > SYNC or ASYNC? > All sends without a CompletionListener will be synchronous. > > 3. Can we make assumption that, If we are send message with > CompletionListener, then Qpid always send message to broker in ASYNC way or > it can be SYNC also with "jms.forceSyncSend=true"? > There is no assumption here, it is asynchronous. CompletionListener only exists to facilitate reliable asynchronous send, providing one is an explicit request for an async send, and as before that option is not there to govern that in any way (and still wouldnt do what you seem to want if it were; results come via CompletionListener) > 4. SYNCHRONOUS - What is the internal behaviour of Qpid in SYNC messaging? > Is qpid waiting for successful response back from broker or it is working > like NON blocking IO concept? > Sync sends return at the application level upon receipt of acknowledgement from the recipient peer (e.g a broker). (The underlying transport is not blocking.) > 5. Is there anyway to identify to nature of SEND call, our SEND call is > ASYNC or SYNC? Proton logs? > > 6. Enforce ASYNC - Can you please tell us best way to enforce ASYNC? > > 7. Enforce SYNC - Can you please tell us best way to enforce SYNC? > I dont think I can add anything I havent already said for these. > > Regards, > Abhishek Kumar > > > > -- > Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
