4

I've a little problem with a simple HTTP GET request that I've written and which will request a URL every X minutes. I had it once or twice a day that the process stopped in the midst of the GET request.

Here's an example of the debug log:

12-07 16:29:22.650 V/TAG(11655): Executing HTTP Request
12-07 16:29:25.336 D/dalvikvm(11655): GC_CONCURRENT freed 366K, 50% free 2824K/5639K, external 0K/0K, paused 3ms+3ms
12-07 16:29:25.526 D/dalvikvm(11655): GC_CONCURRENT freed 450K, 52% free 2825K/5767K, external 0K/0K, paused 2ms+2ms
12-07 16:29:29.990 I/ActivityManager( 1339): Process PackageName:remote (pid 11655) has died.
12-07 16:29:29.990 I/ActivityManager( 1339): Low Memory: No more background processes.

Now this just threw up two problems for me:

  • First, the timeout that I've specified does not work:

        HttpParams httpParameters = new BasicHttpParams();
    int timeoutConnection = 10000;
    HttpConnectionParams.setConnectionTimeout(httpParameters, timeoutConnection);
    int timeoutSocket = 10000;
    HttpConnectionParams.setSoTimeout(httpParameters, timeoutSocket);
    HttpClient client=new DefaultHttpClient(httpParameters);
    HttpGet request=new HttpGet(url);
    Log.v(TAG,"Executing HTTP Request");
    HttpResponse response=client.execute(request);

  • The second problem is that I cannot see a reason why the process has died - is this the 'died' message the same if it is getting killed due to low memory? Because the timeout has not been reached here (client.execute is in a try / catch block)

Thanks for your replies!

Tamás
  • 47,239
  • 12
  • 105
  • 124
s.i.d
  • 53
  • 1
  • 6
  • 1
    Looks like Android killed your process because it was running in the background and it needed the memory. – THelper Dec 08 '11 at 13:16
  • Is it possible to prevent this? – s.i.d Dec 08 '11 at 19:41
  • Yes (by using a service) and no (services can still be killed by Android on low memory, but less likely). Read [this blog](http://android-developers.blogspot.com/2010/04/multitasking-android-way.html), especially the part on "Explicitly running in the background". – THelper Dec 09 '11 at 07:25
  • The process should run on a defined time (all X minutes) and get an URL for the data. I thought that it would be overkill to create a service (wich always runs in the background) - the upper solution is done by calling the class trough the system internal alarm function. Strangely the class dies always at the same position (waiting for the data from the url) - could it not be a problem with the timeouts? Funny is that I measure the response times (and display them in a log) and sometimes it's over 10 seconds (even if I have specified a 10 second timeout)... – s.i.d Dec 09 '11 at 09:57
  • Are you using broadcasts to send/receive the alarm? If so your code needs to be finished in less than 10 seconds (read the part on broadcasts in the blog I mentioned). Your timeout code seems ok, is taking far longer tan 10 secs sometimes? – THelper Dec 09 '11 at 10:14
  • I'm not sure how I send/receive the alarm currently :) I do not have the code in front of me, but I'll check later this day. Currently I following times in the logfile: 5.45s, 45.1s (!), 1.84s, 7s, 5.1s, 5.5s, 4.2s, 173s (!) – s.i.d Dec 09 '11 at 10:23
  • The execution works with an AlarmReceiver (AlarmManager) – s.i.d Dec 10 '11 at 12:41

1 Answers1

2

If I understood you correctly you are asking two things:

  • Q1: Why doesn't the specified timeout work?
  • Q2. Why did the process die?

Starting with Q2, my guess is that your process is killed because the timeout didn't work and your code took too long to run. As a result Android killed it.

As for Q1: I did some experimenting and noticed that in the emulator the timeouts didn't work in my app as well. Testing with the emulator API7 and API8 I always get an UnknownHostException after about 20 seconds, regardless of any set timeout. This goes for the DefaultHttpClient as well as the HttpUrlConnection and AndroidHttpClient.

Googling revealed that other people have also reported problems with timeout:

None of the proposed solutions worked for me, so I guess the only reliable solution is to manage timeouts yourself.

Community
  • 1
  • 1
THelper
  • 15,333
  • 6
  • 64
  • 104
  • I did not find any samples on doing this, do you have a sample by accident? :) – s.i.d Dec 23 '11 at 21:49
  • I noticed that the timeout problem only occurs in the emulator. Testing on a device I got a timeout much faster (even within the set timeout value!?). Nevertheless, I decided to keep my current code so unfortunately I don't have an example of managing timeouts yourself, but maybe [this post](http://stackoverflow.com/q/2356670/741249) will help. – THelper Dec 26 '11 at 11:07