0

I am developing an Angular JS application using ionic. For android, I am using crosswalk for better performance.

I've noticed that when running on Android, I am facing problems with http requests getting stuck when trying to load large images - if any request gets "stuck" -- i.e. no error, but in my chrome developer inspector, I see the http request as "pending" -- then all subsequent requests go into "pending" state too. This problem does not exist in iOS

The code is pretty simple:

 <span ng-repeat="monitor in monitors">
      <img ng-src="http://server.com/monitorId=monitor?view=jpg" />
</span>

This results in around 6 GETs of images of size 600x400 and the images keep changing (the server keeps changing the image)

What I've observed specifically with Android is after a few successful iterations, the network HTTP GET behind this img ng-src gets stuck in pending like I said above and then all subsequent HTTP requests also get into pending and none of them ever get out of that state.

I am guessing there is some sort of limit for network queue that is getting filled up.

So how do I solve this issue?

a) One way I could think of is to put a timeout -- but ng-src does not seem to have a time out function. My thought is on timeout, the http request would cancel - like in normal $http.get functions and this should help.

b) Maybe there is a way to flush all http requests. I saw in SO, someone created a new directive which needs to be added here: AngularJS abort all pending $http requests on route change --> but this needs me to replace http with this new directive --> while I am using img ng-src

c) Neither a nor c are ideal. I'd like to know what is really going on - why does Android balk at this while iOS does not (comparing Galaxy S3 with iPhone 5s). So if you have any other solutions, I'd love to hear them

thanks

Community
  • 1
  • 1
user1361529
  • 2,667
  • 29
  • 61

1 Answers1

1

Wow, this was quite a learning. I managed to implement a work-around.

Edited: For those who think this is due to the limitation of 6 connections- please go through https://code.google.com/p/chromium/issues/detail?id=234779

The problem specifically is Chrome (At least with crosswalk, and maybe chrome in general) has a problem if you open multiple streams of HTTP connections that don't close for a long time. In my case the "img-src" was pointing to an image URL that the server was changing 3 times a second. Each image takes a second or two to download, so data keeps streaming in.

There is something about this that puts Chrome in a tizzy and it starts getting into an eternal pending loop for any HTTP requests after the first pending - even unrelated HTTP requests

Fortunately, I managed to implement a workaround: The server had an option to just get one image (not dynamic). I used that URL and the implemented a $interval timer in that controller that would refresh that URL every second - effectively retrieving images every second (or any other timer value I want)

Chrome has NO problem dealing with the HTTP requests in this way because they are getting closed predictably, even if it means more HTTP requests.

Phew. Not the solution I'd want, but it works very well.

And the gallant iOS handles this well too (it handled the original scenario perfectly too)

user1361529
  • 2,667
  • 29
  • 61
  • "In my case the "img-src" was pointing to an image URL that the server was changing 3 times a second." - how is your server changing the img-src url? – Parv Sharma May 02 '15 at 20:34
  • this link mmight help you understand your problem better http://stackoverflow.com/questions/8404464/increasing-google-chromes-max-connections-per-server-limit-to-more-then-6 – Parv Sharma May 02 '15 at 20:38
  • The url is for the form "foo.com/monitor=1&mode=jpeg&rand=232" --> the server keeps pushing JPEG content in the payload Thanks for the link - its not the problem I was facing. I'm opening many more than 6 concurrent streams and chrome handles it well. It's to do with requests that don't close (which is the case in constant jpeg streaming) – user1361529 May 02 '15 at 20:53