Is it worthwhile reporting this as a bug?

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

Locked
monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Is it worthwhile reporting this as a bug?

Post by monte » Tue Jul 30, 2013 5:16 am

Hi

An app I'm working on is hitting this issue: https://groups.google.com/forum/#!topic ... GnxaoJDFy8

It seems to be occasionally thrown but as far as I can tell only on the first request... request again and it's fine... so here's my workaroundL

Code: Select all

POST pData to theAPIURL()
   if the result is "java.io.EOFException" then
      -- try again
      POST pData to theAPIURL()
   end if
Now it's going to be a little annoying to remember to do that for each url request... should we do the keepAlive false thing or something else?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: Is it worthwhile reporting this as a bug?

Post by LCMark » Wed Jul 31, 2013 11:17 am

Hmmm - if it's a bug in Android that we need to work-around then we should put the work-around in the engine code, after all the engine has to provide the functionality it states even when there are 'bugs' in the system routines.

I guess setting 'keep-alive' false as default would be the definitive way to fix things, but as the report says this impacts performance. I guess we could try the 'trying again' approach first (on EOFException) and see if that works fine in general - if not, we might have to crib copies of the relevant classes out of Android, apply the patch that has been proposed, and use them on system versions that have the problem (which seems to be all of them at the moment).

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Is it worthwhile reporting this as a bug?

Post by monte » Thu Aug 01, 2013 1:05 am

Would keepAlive false be worse performance than two requests?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: Is it worthwhile reporting this as a bug?

Post by LCMark » Thu Aug 01, 2013 9:56 am

Would keepAlive false be worse performance than two requests?
Good point - actually looking at the Wikipedia article about 'HTTP persistent connections' does suggest they perhaps aren't as useful as they once were. So perhaps we should just try turning off keep-alive for now.

As an aside, I'm surprised we haven't had any bug reports about Android HTTP connections being flaky - is it a combination of client and server that causes it, or is it just random? It's not clear from the bug report at android what the circumstances it arises in are.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Is it worthwhile reporting this as a bug?

Post by monte » Thu Aug 01, 2013 10:15 am

It would be a hard one to debug I think because given the same API I've got some posts that consistently fail on first call and some that consistently don't. But it's the same url I'm posting to. The only thing that's changing is what I'm posting (which are JSON objects).
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

bangkok
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 937
Joined: Fri Aug 15, 2008 7:15 am

Re: Is it worthwhile reporting this as a bug?

Post by bangkok » Sun Oct 06, 2013 9:54 pm

Bingo. I have the same bug.

But it's even worst :

-same url
-same port number
-only path change

-with the first query (XMLRPC), it's working fine : Desktop and Android
-with the second one, working fine on Desktop, but i receive the "java.io.EOFException" on Android (2.3.3). Systematically.

Both queries are posted with the same script.

-query 1 is 252 long
-the second one : 749

Now the funny part... if I change the order, firing the query 2 before the query 1... it's working. and the query 1 doesn't work anymore.

I try to put a delay between both queries... several seconds... same problem.

Could it be something related to clear a cache, a buffer between 2 queries ?

Anyway... It's really disturbing.

By using your trick (to post again right away !)... it seems to be okay now. :D

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: Is it worthwhile reporting this as a bug?

Post by LCMark » Wed Oct 09, 2013 9:58 am

I've just filed this as Bug 11266 - http://quality.runrev.com/show_bug.cgi?id=11266

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Is it worthwhile reporting this as a bug?

Post by monte » Wed Oct 09, 2013 11:46 am

Yes... sorry I never got around to that... after asking if it was worthwhile ;-)
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: Is it worthwhile reporting this as a bug?

Post by LCMark » Wed Oct 09, 2013 12:09 pm

@monte: No worries - I forgot about it too... Bug filed and fix integrated into 6.1.2-rc-3.

MWCoastMedia
Posts: 31
Joined: Fri Jan 16, 2015 5:31 pm

Re: Is it worthwhile reporting this as a bug?

Post by MWCoastMedia » Fri Sep 16, 2016 2:51 pm

I just had this issue compiling to Android from 8.0.2(?). Three requests going to the same LiveCode server one after another, but the 2nd call seems to choke recently.

This seemed to take care of it quickly, based off the original post by Monte

Code: Select all

 put sendApiRequest(tTask) into tResponseArray
if tResponseArray is NOT an array then
    // FIX FOR STUPID ANDROID BUG
    if (word -1 of tResponseArray) = "java.io.EOFException" then
         put sendApiRequest(tTask) into tResponseArray
     end if
     --showOutput ("[Error]" & cr & tResponseArray)
end if  // tResponseArray is NOT an array

Locked

Return to “Engine Contributors”