Re: Messenger race condition on Android?

2016-02-01 Thread tourili
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?

2015-04-27 Thread Rafael Schloming
On Mon, Apr 20, 2015 at 8:12 PM, Adam Wynne awy...@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+s2158936n7623117...@n2.nabble.com wrote:

  On Fri, Apr 17, 2015 at 8:09 AM, Adam Wynne [hidden email]
  http:///user/SendEmail.jtp?type=nodenode=7623117i=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?

2015-04-20 Thread Adam Wynne
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+s2158936n7623117...@n2.nabble.com wrote:

 On Fri, Apr 17, 2015 at 8:09 AM, Adam Wynne [hidden email]
 http:///user/SendEmail.jtp?type=nodenode=7623117i=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_codenode=7623116code=YXd5bm5lQGdtYWlsLmNvbXw3NjIzMTE2fDkyMjA4OTk2MQ==
 .
 NAML
 http://qpid.2158936.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=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?

2015-04-17 Thread Rafael Schloming
On Fri, Apr 17, 2015 at 8:09 AM, Adam Wynne awy...@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