how to maintain reliability with ASYNC operation?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

how to maintain reliability with ASYNC operation?

akabhishek1
Hi Team,

We are using "qpid-jms-client-0.40.0" to send messages to Azure ServiceBus.
At this moment, we are using "jms.forceSyncSend=true" to avoid message loss.

We got the requirement to publish message asynchronously for better
throughtput.

I have few questions around ASYNC operation to use it effectively in our
estate -
- How async operation are handling the messages internally (documentation is
very thin)
- Is this making network call to broker and waiting for responses?
- How the message reliability is maintained?  
- what are the downsides of using ASYNC from a library usage perspective?

Any insights, you can offer here.

Regards,
Abhishek Kumar





--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: how to maintain reliability with ASYNC operation?

Robbie Gemmell
Administrator
If you want to do reliable async sends then you need to make use of a
CompletionListener to track/handle the async send completion, e.g:
https://docs.oracle.com/javaee/7/api/javax/jms/MessageProducer.html#send-javax.jms.Message-javax.jms.CompletionListener-

The client then sends the message but does not wait for a response.
The send call will block (if needed) for the sending link to have
credit to send the message before returning. After the send call
returns your CompletionListener tracks/handles completion of the send,
successfully or otherwise. While an async send has yet to be
completed, the Message object should not be accessed.

Almost all of this is documented in the JMS spec, e.g the link above.

Robbie

On Thu, 6 Jun 2019 at 12:29, akabhishek1
<[hidden email]> wrote:

>
> Hi Team,
>
> We are using "qpid-jms-client-0.40.0" to send messages to Azure ServiceBus.
> At this moment, we are using "jms.forceSyncSend=true" to avoid message loss.
>
> We got the requirement to publish message asynchronously for better
> throughtput.
>
> I have few questions around ASYNC operation to use it effectively in our
> estate -
> - How async operation are handling the messages internally (documentation is
> very thin)
> - Is this making network call to broker and waiting for responses?
> - How the message reliability is maintained?
> - what are the downsides of using ASYNC from a library usage perspective?
>
> Any insights, you can offer here.
>
> Regards,
> Abhishek Kumar
>
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: how to maintain reliability with ASYNC operation?

akabhishek1
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??
   

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?

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?


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"?

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?

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?


Regards,
Abhishek Kumar



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: how to maintain reliability with ASYNC operation?

Robbie Gemmell
Administrator
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
<[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: how to maintain reliability with ASYNC operation?

Robbie Gemmell
Administrator
I have tweaked the docs to note that implicitly(/explicitly)
asynchronous CompletionListener related sends are not governed by that
option. The site will reflect that upon the next release.

Robbie

On Mon, 10 Jun 2019 at 16:30, Robbie Gemmell <[hidden email]> wrote:
<snipped>
>
> 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.
>
<snipped>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: how to maintain reliability with ASYNC operation?

Robbie Gemmell
Administrator
In reply to this post by Robbie Gemmell
On Mon, 10 Jun 2019 at 16:30, Robbie Gemmell <[hidden email]> wrote:

>
> 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
> <[hidden email]> 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.

I must have misread this bit (maybe mangled it together with another
question), thinking the option was being set true. As it is not, the
comment should have been the same as the previous one above.

>
> >
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: how to maintain reliability with ASYNC operation?

akabhishek1
Hi Robbie,

Thank you so much for your all inputs. I really appreciate your fast
response.

We are doing testing based on your inputs. We will come back again, if we
have any other questions.

Regards,
Abhishek Kumar



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: how to maintain reliability with ASYNC operation?

akabhishek1
In reply to this post by Robbie Gemmell
Hi Robbie,

Based on your input, i did some testing and got different test result in
terms of TPS(transaction per second) for below conditions

1. jms.forceSyncSend=true + send(jmsMsg, PERSISTENT, DEFAULT_PRIORITY,
DEFAULT_TIME_TO_LIVE)  -- > I got TPS around 1200.

2. NO Setting @Connection Level + send(jmsMsg, PERSISTENT, DEFAULT_PRIORITY,
DEFAULT_TIME_TO_LIVE)  -- > I got TPS around 1800.


As both conditions tend to SYNCHRONOUS. I wondered to see different test
result with variance of 600TPS. My sourceCode is completely same for both
conditions except setting at connection level.

Expectation - As both conditions tend to SYNCHRONOUS, so i am expecting
approx. same TPS for both conditions.

Could you please provide some insights, why i am getting different Test
throughput as both are synchronous? Am i missing something?

Client - qpid-jms-client-0.43.0
Java8
Broker - Azure ServiceBus(Premium)

Regards,
Abhishek Kumar



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: how to maintain reliability with ASYNC operation?

Robbie Gemmell
Administrator
That would be the very point that I corrected myself on earlier, where
I had somehow misread the second question numbered 2 originally. Per
the correction, the same answer to the first question 2 applied there
also, which was "This is the same as the default. Persistent messages
will be sent synchronously, except inside a transaction.
Non-persistent messages will be sent asynchronously." Governing those
cases is the reason the forceSyncSend option exists.

Robbie

On Tue, 11 Jun 2019 at 17:23, akabhishek1
<[hidden email]> wrote:

>
> Hi Robbie,
>
> Based on your input, i did some testing and got different test result in
> terms of TPS(transaction per second) for below conditions
>
> 1. jms.forceSyncSend=true + send(jmsMsg, PERSISTENT, DEFAULT_PRIORITY,
> DEFAULT_TIME_TO_LIVE)  -- > I got TPS around 1200.
>
> 2. NO Setting @Connection Level + send(jmsMsg, PERSISTENT, DEFAULT_PRIORITY,
> DEFAULT_TIME_TO_LIVE)  -- > I got TPS around 1800.
>
>
> As both conditions tend to SYNCHRONOUS. I wondered to see different test
> result with variance of 600TPS. My sourceCode is completely same for both
> conditions except setting at connection level.
>
> Expectation - As both conditions tend to SYNCHRONOUS, so i am expecting
> approx. same TPS for both conditions.
>
> Could you please provide some insights, why i am getting different Test
> throughput as both are synchronous? Am i missing something?
>
> Client - qpid-jms-client-0.43.0
> Java8
> Broker - Azure ServiceBus(Premium)
>
> Regards,
> Abhishek Kumar
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]