You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Adam Wynne <aw...@gmail.com> on 2015/04/17 14:09:23 UTC
Messenger race condition on Android?
Sorry for the cross-post but I didn't get any hits on the user list and I now
think this could be a bug.
I think I am seeing a race condition with Messenger on Android only:
When I do the typical put/send sequence in a Thread started from an Android
Activity, the message is not received by a subscribed peer. If I kill the
Activity, the peer will complain that the connection is broken. So it
seems that the connection is being made but the data is not sent. Here is
an example code snippet:
Messenger messenger = Messenger.Factory.create();
// do other things like create a message
messenger.put(msg)
// Thread.sleep(200)
messenger.send()
However when I uncomment the sleep statement above, the message is
received without any problem. The message is also received if I attempt
to debug to see what is happening in put().
I noticed that put() does not simply add the message to a queue, it also
uses nio methods to do some encoding of the message. I'm wondering if
since it is not blocking, is there some encoding method happening while the
send() is being processed, causing the message to be lost.
We also noticed that there is a big CPU usage (up to 40%) spike during the
put/send process, which seems extreme for just a tcp send.
--
View this message in context: http://qpid.2158936.n2.nabble.com/Messenger-race-condition-on-Android-tp7623116.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: Messenger race condition on Android?
Posted by tourili <iy...@hotmail.com>.
Hi Adam
I am interested in how are you using the messenger api on android?
Which proton project are u using? on what android platform are you runing
that
Thank you
--
View this message in context: http://qpid.2158936.n2.nabble.com/Messenger-race-condition-on-Android-tp7623116p7637713.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: Messenger race condition on Android?
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Mon, Apr 20, 2015 at 8:12 PM, Adam Wynne <aw...@gmail.com> wrote:
> Hi Rafael,
>
> My answers to your questions are below...
>
> On Fri, Apr 17, 2015 at 8:33 AM Rafael Schloming-3 [via Qpid] <
> ml-node+s2158936n7623117h77@n2.nabble.com> wrote:
>
> > On Fri, Apr 17, 2015 at 8:09 AM, Adam Wynne <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=7623117&i=0>> wrote:
> >
> > > Sorry for the cross-post but I didn't get any hits on the user list and
> > I
> > > now
> > > think this could be a bug.
> > >
> > > I think I am seeing a race condition with Messenger on Android only:
> > >
> > > When I do the typical put/send sequence in a Thread started from an
> > Android
> > > Activity, the message is not received by a subscribed peer. If I kill
> > the
> > > Activity, the peer will complain that the connection is broken. So it
> > > seems that the connection is being made but the data is not sent. Here
> > is
> > > an example code snippet:
> > >
> > > Messenger messenger = Messenger.Factory.create();
> > > // do other things like create a message
> > > messenger.put(msg)
> > > // Thread.sleep(200)
> > > messenger.send()
> > >
> > > However when I uncomment the sleep statement above, the message is
> > > received without any problem. The message is also received if I
> > attempt
> > > to debug to see what is happening in put().
> > >
> > > I noticed that put() does not simply add the message to a queue, it
> also
> > > uses nio methods to do some encoding of the message. I'm wondering if
> > > since it is not blocking, is there some encoding method happening while
> > the
> > > send() is being processed, causing the message to be lost.
> > >
> > > We also noticed that there is a big CPU usage (up to 40%) spike during
> > the
> > > put/send process, which seems extreme for just a tcp send.
> > >
> >
> > Hi Adam,
> >
> > Apologies in advance for the barrage of questions, but some additional
> > information would be helpful.
> >
> > What version of the code are you working with?
> >
> I first tried with 0.9, then I built the latest from source and had the
> same results each time
>
> > Is your thread a long running thread or does it terminate shortly after
> > the
> > code you have posted?
> >
> The thread is long running
>
> > What exactly is receiving the message at the other end of the connection?
> >
> I have tried 2 subscribers with the same results: one in android and one
> on a macbook. I get the same results on mac.
>
> > Does a similar thread arrangement reproduce the issue outside of Android,
> > and if so would it be possible to post a reproducer?
> >
> No, I couldn't reproduce in a standard JVM. Do you want me to post the
> android app?
>
That would certainly be helpful.
--Rafael
Re: Messenger race condition on Android?
Posted by Adam Wynne <aw...@gmail.com>.
Hi Rafael,
My answers to your questions are below...
On Fri, Apr 17, 2015 at 8:33 AM Rafael Schloming-3 [via Qpid] <
ml-node+s2158936n7623117h77@n2.nabble.com> wrote:
> On Fri, Apr 17, 2015 at 8:09 AM, Adam Wynne <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=7623117&i=0>> wrote:
>
> > Sorry for the cross-post but I didn't get any hits on the user list and
> I
> > now
> > think this could be a bug.
> >
> > I think I am seeing a race condition with Messenger on Android only:
> >
> > When I do the typical put/send sequence in a Thread started from an
> Android
> > Activity, the message is not received by a subscribed peer. If I kill
> the
> > Activity, the peer will complain that the connection is broken. So it
> > seems that the connection is being made but the data is not sent. Here
> is
> > an example code snippet:
> >
> > Messenger messenger = Messenger.Factory.create();
> > // do other things like create a message
> > messenger.put(msg)
> > // Thread.sleep(200)
> > messenger.send()
> >
> > However when I uncomment the sleep statement above, the message is
> > received without any problem. The message is also received if I
> attempt
> > to debug to see what is happening in put().
> >
> > I noticed that put() does not simply add the message to a queue, it also
> > uses nio methods to do some encoding of the message. I'm wondering if
> > since it is not blocking, is there some encoding method happening while
> the
> > send() is being processed, causing the message to be lost.
> >
> > We also noticed that there is a big CPU usage (up to 40%) spike during
> the
> > put/send process, which seems extreme for just a tcp send.
> >
>
> Hi Adam,
>
> Apologies in advance for the barrage of questions, but some additional
> information would be helpful.
>
> What version of the code are you working with?
>
I first tried with 0.9, then I built the latest from source and had the
same results each time
> Is your thread a long running thread or does it terminate shortly after
> the
> code you have posted?
>
The thread is long running
> What exactly is receiving the message at the other end of the connection?
>
I have tried 2 subscribers with the same results: one in android and one
on a macbook. I get the same results on mac.
> Does a similar thread arrangement reproduce the issue outside of Android,
> and if so would it be possible to post a reproducer?
>
No, I couldn't reproduce in a standard JVM. Do you want me to post the
android app?
>
> Thanks,
>
> --Rafael
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://qpid.2158936.n2.nabble.com/Messenger-race-condition-on-Android-tp7623116p7623117.html
> To unsubscribe from Messenger race condition on Android?, click here
> <http://qpid.2158936.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=7623116&code=YXd5bm5lQGdtYWlsLmNvbXw3NjIzMTE2fDkyMjA4OTk2MQ==>
> .
> NAML
> <http://qpid.2158936.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://qpid.2158936.n2.nabble.com/Messenger-race-condition-on-Android-tp7623116p7623203.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: Messenger race condition on Android?
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Fri, Apr 17, 2015 at 8:09 AM, Adam Wynne <aw...@gmail.com> wrote:
> Sorry for the cross-post but I didn't get any hits on the user list and I
> now
> think this could be a bug.
>
> I think I am seeing a race condition with Messenger on Android only:
>
> When I do the typical put/send sequence in a Thread started from an Android
> Activity, the message is not received by a subscribed peer. If I kill the
> Activity, the peer will complain that the connection is broken. So it
> seems that the connection is being made but the data is not sent. Here is
> an example code snippet:
>
> Messenger messenger = Messenger.Factory.create();
> // do other things like create a message
> messenger.put(msg)
> // Thread.sleep(200)
> messenger.send()
>
> However when I uncomment the sleep statement above, the message is
> received without any problem. The message is also received if I attempt
> to debug to see what is happening in put().
>
> I noticed that put() does not simply add the message to a queue, it also
> uses nio methods to do some encoding of the message. I'm wondering if
> since it is not blocking, is there some encoding method happening while the
> send() is being processed, causing the message to be lost.
>
> We also noticed that there is a big CPU usage (up to 40%) spike during the
> put/send process, which seems extreme for just a tcp send.
>
Hi Adam,
Apologies in advance for the barrage of questions, but some additional
information would be helpful.
What version of the code are you working with?
Is your thread a long running thread or does it terminate shortly after the
code you have posted?
What exactly is receiving the message at the other end of the connection?
Does a similar thread arrangement reproduce the issue outside of Android,
and if so would it be possible to post a reproducer?
Thanks,
--Rafael