tomgibara wrote:
> Phew... this has taken me many many hours to track down, mostly
> because I stumbled across it in the middle of some dense resource
> management code - and the problem is actually very far from there...

> Here's a test method (with a trivial subsidiary method) that makes two
> sequential requests to the same server using two different GetMethod
> objects sharing one HttpClient object - I presume a very common
> situation:

>     private void testSequentialGet(String url) {
>         HttpClient client = new HttpClient();
>         byte[] buffer = new byte[8192];
>         try {

>             GetMethod get1 = new GetMethod(url);
>             try {
>                    int status = client.executeMethod(get1);
>                    Log.i("test", "Status for " + url + " (1) = " + status);
>                    long read = exhaust(get1.getResponseBodyAsStream(),
> buffer);
>                    Log.i("test", "Bytes read for " + url + " (1) = " +
> read);
>             } finally {
>                    get1.releaseConnection();
>             }

>             GetMethod get2 = new GetMethod(url);
>             try {
>                    int status = client.executeMethod(get2);
>                    Log.i("test", "Status for " + url + " (2) = " + status);
>                    long read = exhaust(get2.getResponseBodyAsStream(),
> buffer);
>                    Log.i("test", "Bytes read for " + url + " (2) = " +
> read);
>             } finally {
>                 get2.releaseConnection();
>             }
>         } catch (HttpException e) {
>             Log.i("test", "Test of " + url + " failed with an HTTP
> exception.", e);
>         } catch (IOException e) {
>             Log.i("test", "Test of " + url + " failed with an IO
> exception.", e);
>         }
>     }

>     private static long exhaust(final InputStream in, byte[] buffer)
> throws IOException {
>         long read = 0L;
>         try {
>             for (int r = 0; r >= 0; r = in.read(buffer)) read += r;
>         } finally {
>             try {
>                    in.close();
>             } catch (IOException e) { }
>         }
>         return read;
>     }

> We can call this method (using the latest version of the emulator to-
> date: m3-rc37) with a number of different URLs:

> testSequentialGet("http://www.google.com");
> testSequentialGet("http://www.apache.org");
> testSequentialGet("http://www.microsoft.com");

> and the resulting output in the log is:

> I/test(656): Status for http://www.google.com (1) = 200
> I/test(656): Bytes read for http://www.google.com (1) = 5424
> I/test(656): Status for http://www.google.com (2) = 200
> I/test(656): Bytes read for http://www.google.com (2) = 5424

> I/test(656): Status for http://www.apache.org (1) = 200
> I/test(656): Bytes read for http://www.apache.org (1) = 17409
> I/test(656): Test of http://www.apache.org failed with an IO
> exception.

> I/test(656): Test of http://www.microsoft.com failed with an IO
> exception.
> I/test(656): java.io.InterruptedIOException: Read timed out

> Repeated requests to Google work as expected. The first request to
> Apache (running a development version of the Apache webserver)
> succeeds but the second request fails. The first request to Microsoft
> (running IIS7) fails. These are, as far as I can confirm, entirely
> reproducible exceptions, and I don't think I'm making any mistakes in
> my use of the Jakarta HttpClient library. Nor am I behind a proxy
> server.

> Anecdotally, I think that the problems may be related to HTTP/1.1 Keep
> Alives. I have three pieces of evidence for this. Firstly, disabling
> Keep Alives on my local development server (which is where I first
> encountered the problem) seemed to remove the exception. Secondly, I
> briefly looked online for a popular site that runs with Keep Alives
> disabled, I found Slashdot (http://slashdot.org) which runs in this
> way (on an Apache webserver); repeated requests to the /. homepage do
> not trigger an exception. Thirdly, the exception itself (which I don't
> have the motivation to investigate further at this time) is the same
> in every case and looks like this:

> I/test(680):     at
> org.apache.harmony.luni.platform.OSFileSystem.readImpl(Native Method)
> I/test(680):     at
> org.apache.harmony.luni.platform.OSFileSystem.read(OSFileSystem.java:
> 150)
> I/test(680):     at java.io.FileInputStream.read(FileInputStream.java:
> 306)
> I/test(680):     at
> java.io.BufferedInputStream.fillbuf(BufferedInputStream.java:173)
> I/test(680):     at
> java.io.BufferedInputStream.read(BufferedInputStream.java:228)
> I/test(680):     at
> org.apache.commons.httpclient.HttpConnection.isStale(HttpConnection.java:
> 509)
> I/test(680):     at
> org.apache.commons.httpclient.HttpConnection.closeIfStale(HttpConnection.ja va:
> 434)
> I/test(680):     at
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMetho dDirector.java:
> 381)
> I/test(680):     at
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDi rector.java:
> 170)
> I/test(680):     at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> 398)
> I/test(680):     at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> 326)

> Checking for stale connections might have some interaction with
> persistent connections?

> There are numerous plausible workarounds; if this bug is not to be
> fixed soon, I welcome any advice on the best workaround to adopt since
> I don't have a handle on its scope.

> Phew... this has taken me many many hours to track down, mostly
> because I stumbled across it in the middle of some dense resource
> management code - and the problem is actually very far from there...

> Here's a test method (with a trivial subsidiary method) that makes two
> sequential requests to the same server using two different GetMethod
> objects sharing oneHttpClientobject - I presume a very common
> situation:

>     private void testSequentialGet(String url) {
>        HttpClientclient = newHttpClient();
>         byte[] buffer = new byte[8192];
>         try {

>             GetMethod get1 = new GetMethod(url);
>             try {
>                 int status = client.executeMethod(get1);
>                 Log.i("test", "Status for " + url + " (1) = " + status);
>                 long read = exhaust(get1.getResponseBodyAsStream(),
> buffer);
>                 Log.i("test", "Bytes read for " + url + " (1) = " +
> read);
>             } finally {
>                 get1.releaseConnection();
>             }

>             GetMethod get2 = new GetMethod(url);
>             try {
>                 int status = client.executeMethod(get2);
>                 Log.i("test", "Status for " + url + " (2) = " + status);
>                 long read = exhaust(get2.getResponseBodyAsStream(),
> buffer);
>                 Log.i("test", "Bytes read for " + url + " (2) = " +
> read);
>             } finally {
>                 get2.releaseConnection();
>             }
>         } catch (HttpException e) {
>             Log.i("test", "Test of " + url + " failed with an HTTP
> exception.", e);
>         } catch (IOException e) {
>             Log.i("test", "Test of " + url + " failed with an IO
> exception.", e);
>         }
>     }

>     private static long exhaust(final InputStream in, byte[] buffer)
> throws IOException {
>         long read = 0L;
>         try {
>             for (int r = 0; r >= 0; r = in.read(buffer)) read += r;
>         } finally {
>             try {
>                 in.close();
>             } catch (IOException e) { }
>         }
>         return read;
>     }

> We can call this method (using the latest version of the emulator to-
> date: m3-rc37) with a number of different URLs:

> testSequentialGet("http://www.google.com");
> testSequentialGet("http://www.apache.org");
> testSequentialGet("http://www.microsoft.com");

> and the resulting output in the log is:

> I/test(656): Status forhttp://www.google.com(1) = 200
> I/test(656): Bytes read forhttp://www.google.com(1) = 5424
> I/test(656): Status forhttp://www.google.com(2) = 200
> I/test(656): Bytes read forhttp://www.google.com(2) = 5424

> I/test(656): Status forhttp://www.apache.org(1) = 200
> I/test(656): Bytes read forhttp://www.apache.org(1) = 17409
> I/test(656): Test ofhttp://www.apache.orgfailed with an IO
> exception.

> I/test(656): Test ofhttp://www.microsoft.comfailed with an IO
> exception.
> I/test(656): java.io.InterruptedIOException: Read timed out

> Repeated requests to Google work as expected. The first request to
> Apache (running a development version of the Apache webserver)
> succeeds but the second request fails. The first request to Microsoft
> (running IIS7) fails. These are, as far as I can confirm, entirely
> reproducible exceptions, and I don't think I'm making any mistakes in
> my use of the JakartaHttpClientlibrary. Nor am I behind a proxy
> server.

> Anecdotally, I think that the problems may be related to HTTP/1.1 Keep
> Alives. I have three pieces of evidence for this. Firstly, disabling
> Keep Alives on my local development server (which is where I first
> encountered the problem) seemed to remove the exception. Secondly, I
> briefly looked online for a popular site that runs with Keep Alives
> disabled, I found Slashdot (http://slashdot.org) which runs in this
> way (on an Apache webserver); repeated requests to the /. homepage do
> not trigger an exception. Thirdly, the exception itself (which I don't
> have the motivation to investigate further at this time) is the same
> in every case and looks like this:

> I/test(680):     at
> org.apache.harmony.luni.platform.OSFileSystem.readImpl(Native Method)
> I/test(680):     at
> org.apache.harmony.luni.platform.OSFileSystem.read(OSFileSystem.java:
> 150)
> I/test(680):     at java.io.FileInputStream.read(FileInputStream.java:
> 306)
> I/test(680):     at
> java.io.BufferedInputStream.fillbuf(BufferedInputStream.java:173)
> I/test(680):     at
> java.io.BufferedInputStream.read(BufferedInputStream.java:228)
> I/test(680):     at
> org.apache.commons.httpclient.HttpConnection.isStale(HttpConnection.java:
> 509)
> I/test(680):     at
> org.apache.commons.httpclient.HttpConnection.closeIfStale(HttpConnection.ja va:
> 434)
> I/test(680):     at
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMetho dDirector.java:
> 381)
> I/test(680):     at
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDi rector.java:
> 170)
> I/test(680):     at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> 398)
> I/test(680):     at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> 326)

> Checking forstaleconnections might have some interaction with
> persistent connections?

> There are numerous plausible workarounds; if this bug is not to be
> fixed soon, I welcome any advice on the best workaround to adopt since
> I don't have a handle on its scope.

> Hi! I had the same problem - the workaround is rather simple:

> httpclient.getHttpConnectionManager().getParams().setStaleCheckingEnabled(f alse);

> On Dec 31 2007, 1:41 am, tomgibara <tomgib...@hotmail.com> wrote:

> > Phew... this has taken me many many hours to track down, mostly
> > because I stumbled across it in the middle of some dense resource
> > management code - and the problem is actually very far from there...

> > Here's a test method (with a trivial subsidiary method) that makes two
> > sequential requests to the same server using two different GetMethod
> > objects sharing oneHttpClientobject - I presume a very common
> > situation:

> >     private void testSequentialGet(String url) {
> >        HttpClientclient = newHttpClient();
> >         byte[] buffer = new byte[8192];
> >         try {

> >             GetMethod get1 = new GetMethod(url);
> >             try {
> >                 int status = client.executeMethod(get1);
> >                 Log.i("test", "Status for " + url + " (1) = " + status);
> >                 long read = exhaust(get1.getResponseBodyAsStream(),
> > buffer);
> >                 Log.i("test", "Bytes read for " + url + " (1) = " +
> > read);
> >             } finally {
> >                 get1.releaseConnection();
> >             }

> >             GetMethod get2 = new GetMethod(url);
> >             try {
> >                 int status = client.executeMethod(get2);
> >                 Log.i("test", "Status for " + url + " (2) = " + status);
> >                 long read = exhaust(get2.getResponseBodyAsStream(),
> > buffer);
> >                 Log.i("test", "Bytes read for " + url + " (2) = " +
> > read);
> >             } finally {
> >                 get2.releaseConnection();
> >             }
> >         } catch (HttpException e) {
> >             Log.i("test", "Test of " + url + " failed with an HTTP
> > exception.", e);
> >         } catch (IOException e) {
> >             Log.i("test", "Test of " + url + " failed with an IO
> > exception.", e);
> >         }
> >     }

> >     private static long exhaust(final InputStream in, byte[] buffer)
> > throws IOException {
> >         long read = 0L;
> >         try {
> >             for (int r = 0; r >= 0; r = in.read(buffer)) read += r;
> >         } finally {
> >             try {
> >                 in.close();
> >             } catch (IOException e) { }
> >         }
> >         return read;
> >     }

> > We can call this method (using the latest version of the emulator to-
> > date: m3-rc37) with a number of different URLs:

> > testSequentialGet("http://www.google.com");
> > testSequentialGet("http://www.apache.org");
> > testSequentialGet("http://www.microsoft.com");

> > and the resulting output in the log is:

> > I/test(656): Status forhttp://www.google.com(1) = 200
> > I/test(656): Bytes read forhttp://www.google.com(1) = 5424
> > I/test(656): Status forhttp://www.google.com(2) = 200
> > I/test(656): Bytes read forhttp://www.google.com(2) = 5424

> > I/test(656): Status forhttp://www.apache.org(1) = 200
> > I/test(656): Bytes read forhttp://www.apache.org(1) = 17409
> > I/test(656): Test ofhttp://www.apache.orgfailedwith an IO
> > exception.

> > I/test(656): Test ofhttp://www.microsoft.comfailedwith an IO
> > exception.
> > I/test(656): java.io.InterruptedIOException: Read timed out

> > Repeated requests to Google work as expected. The first request to
> > Apache (running a development version of the Apache webserver)
> > succeeds but the second request fails. The first request to Microsoft
> > (running IIS7) fails. These are, as far as I can confirm, entirely
> > reproducible exceptions, and I don't think I'm making any mistakes in
> > my use of the JakartaHttpClientlibrary. Nor am I behind a proxy
> > server.

> > Anecdotally, I think that the problems may be related to HTTP/1.1 Keep
> > Alives. I have three pieces of evidence for this. Firstly, disabling
> > Keep Alives on my local development server (which is where I first
> > encountered the problem) seemed to remove the exception. Secondly, I
> > briefly looked online for a popular site that runs with Keep Alives
> > disabled, I found Slashdot (http://slashdot.org) which runs in this
> > way (on an Apache webserver); repeated requests to the /. homepage do
> > not trigger an exception. Thirdly, the exception itself (which I don't
> > have the motivation to investigate further at this time) is the same
> > in every case and looks like this:

> > I/test(680):     at
> > org.apache.harmony.luni.platform.OSFileSystem.readImpl(Native Method)
> > I/test(680):     at
> > org.apache.harmony.luni.platform.OSFileSystem.read(OSFileSystem.java:
> > 150)
> > I/test(680):     at java.io.FileInputStream.read(FileInputStream.java:
> > 306)
> > I/test(680):     at
> > java.io.BufferedInputStream.fillbuf(BufferedInputStream.java:173)
> > I/test(680):     at
> > java.io.BufferedInputStream.read(BufferedInputStream.java:228)
> > I/test(680):     at
> > org.apache.commons.httpclient.HttpConnection.isStale(HttpConnection.java:
> > 509)
> > I/test(680):     at
> > org.apache.commons.httpclient.HttpConnection.closeIfStale(HttpConnection.ja va:
> > 434)
> > I/test(680):     at
> > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMetho dDirector.java:
> > 381)
> > I/test(680):     at
> > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDi rector.java:
> > 170)
> > I/test(680):     at
> > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> > 398)
> > I/test(680):     at
> > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> > 326)

> > Checking forstaleconnections might have some interaction with
> > persistent connections?

> > There are numerous plausible workarounds; if this bug is not to be
> > fixed soon, I welcome any advice on the best workaround to adopt since
> > I don't have a handle on its scope.

> Thanks for that workaround, I'll try it out. As I hinted in my
> posting, I was too tired at the time to pursue it further and have
> ignored the problem since then (side stepping it mostly by not reusing
> HttpClient instances) so I'm glad you took the time to post your
> workaround.

> The docs for the method state:

> Defines whether stale connection check is to be used. Disabling stale
> connection check may result in slight performance improvement at the
> risk of getting an I/O error when executing a request over a
> connection that has been closed at the server side.

> I presume this is referring to the situation when a server times-out a
> 'kept-alive' HTTP session. I don't know how often that will happen
> since I expect it depends on the behaviour of the HttpClient library
> code. Anyway, it's got to be better than the workaround I've been
> using.

> On Jan 19, 11:51 pm, fry <bender...@gmail.com> wrote:

> > Hi! I had the same problem - the workaround is rather simple:

> > httpclient.getHttpConnectionManager().getParams().setStaleCheckingEnabled(f alse);

> > On Dec 31 2007, 1:41 am, tomgibara <tomgib...@hotmail.com> wrote:

> > > Phew... this has taken me many many hours to track down, mostly
> > > because I stumbled across it in the middle of some dense resource
> > > management code - and the problem is actually very far from there...

> > > Here's a test method (with a trivial subsidiary method) that makes two
> > > sequential requests to the same server using two different GetMethod
> > > objects sharing oneHttpClientobject - I presume a very common
> > > situation:

> > >     private void testSequentialGet(String url) {
> > >        HttpClientclient = newHttpClient();
> > >         byte[] buffer = new byte[8192];
> > >         try {

> > >             GetMethod get1 = new GetMethod(url);
> > >             try {
> > >                 int status = client.executeMethod(get1);
> > >                 Log.i("test", "Status for " + url + " (1) = " + status);
> > >                 long read = exhaust(get1.getResponseBodyAsStream(),
> > > buffer);
> > >                 Log.i("test", "Bytes read for " + url + " (1) = " +
> > > read);
> > >             } finally {
> > >                 get1.releaseConnection();
> > >             }

> > >             GetMethod get2 = new GetMethod(url);
> > >             try {
> > >                 int status = client.executeMethod(get2);
> > >                 Log.i("test", "Status for " + url + " (2) = " + status);
> > >                 long read = exhaust(get2.getResponseBodyAsStream(),
> > > buffer);
> > >                 Log.i("test", "Bytes read for " + url + " (2) = " +
> > > read);
> > >             } finally {
> > >                 get2.releaseConnection();
> > >             }
> > >         } catch (HttpException e) {
> > >             Log.i("test", "Test of " + url + " failed with an HTTP
> > > exception.", e);
> > >         } catch (IOException e) {
> > >             Log.i("test", "Test of " + url + " failed with an IO
> > > exception.", e);
> > >         }
> > >     }

> > >     private static long exhaust(final InputStream in, byte[] buffer)
> > > throws IOException {
> > >         long read = 0L;
> > >         try {
> > >             for (int r = 0; r >= 0; r = in.read(buffer)) read += r;
> > >         } finally {
> > >             try {
> > >                 in.close();
> > >             } catch (IOException e) { }
> > >         }
> > >         return read;
> > >     }

> > > We can call this method (using the latest version of the emulator to-
> > > date: m3-rc37) with a number of different URLs:

> > > testSequentialGet("http://www.google.com");
> > > testSequentialGet("http://www.apache.org");
> > > testSequentialGet("http://www.microsoft.com");

> > > and the resulting output in the log is:

> > > I/test(656): Status forhttp://www.google.com(1) = 200
> > > I/test(656): Bytes read forhttp://www.google.com(1) = 5424
> > > I/test(656): Status forhttp://www.google.com(2) = 200
> > > I/test(656): Bytes read forhttp://www.google.com(2) = 5424

> > > I/test(656): Status forhttp://www.apache.org(1) = 200
> > > I/test(656): Bytes read forhttp://www.apache.org(1) = 17409
> > > I/test(656): Test ofhttp://www.apache.orgfailedwithan IO
> > > exception.

> > > I/test(656): Test ofhttp://www.microsoft.comfailedwithan IO
> > > exception.
> > > I/test(656): java.io.InterruptedIOException: Read timed out

> > > Repeated requests to Google work as expected. The first request to
> > > Apache (running a development version of the Apache webserver)
> > > succeeds but the second request fails. The first request to Microsoft
> > > (running IIS7) fails. These are, as far as I can confirm, entirely
> > > reproducible exceptions, and I don't think I'm making any mistakes in
> > > my use of the JakartaHttpClientlibrary. Nor am I behind a proxy
> > > server.

> > > Anecdotally, I think that the problems may be related to HTTP/1.1 Keep
> > > Alives. I have three pieces of evidence for this. Firstly, disabling
> > > Keep Alives on my local development server (which is where I first
> > > encountered the problem) seemed to remove the exception. Secondly, I
> > > briefly looked online for a popular site that runs with Keep Alives
> > > disabled, I found Slashdot (http://slashdot.org) which runs in this
> > > way (on an Apache webserver); repeated requests to the /. homepage do
> > > not trigger an exception. Thirdly, the exception itself (which I don't
> > > have the motivation to investigate further at this time) is the same
> > > in every case and looks like this:

> > > I/test(680):     at
> > > org.apache.harmony.luni.platform.OSFileSystem.readImpl(Native Method)
> > > I/test(680):     at
> > > org.apache.harmony.luni.platform.OSFileSystem.read(OSFileSystem.java:
> > > 150)
> > > I/test(680):     at java.io.FileInputStream.read(FileInputStream.java:
> > > 306)
> > > I/test(680):     at
> > > java.io.BufferedInputStream.fillbuf(BufferedInputStream.java:173)
> > > I/test(680):     at
> > > java.io.BufferedInputStream.read(BufferedInputStream.java:228)
> > > I/test(680):     at
> > > org.apache.commons.httpclient.HttpConnection.isStale(HttpConnection.java:
> > > 509)
> > > I/test(680):     at
> > > org.apache.commons.httpclient.HttpConnection.closeIfStale(HttpConnection.ja va:
> > > 434)
> > > I/test(680):     at
> > > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMetho dDirector.java:
> > > 381)
> > > I/test(680):     at
> > > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDi rector.java:
> > > 170)
> > > I/test(680):     at
> > > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> > > 398)
> > > I/test(680):     at
> > > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> > > 326)

> > > Checking forstaleconnections might have some interaction with
> > > persistent connections?

> > > There are numerous plausible workarounds; if this bug is not to be
> > > fixed soon, I welcome any advice on the best workaround to adopt since
> > > I don't have a handle on its scope.

> I meant it is simple that it is just one line code, but it was not
> really simple to find it :)

> As for the disabling StaleChecking, currently I really do not care if
> it would bring some instability in some cases - for me it is more than
> enough that it just works at current moment - I could not find even
> such workarounds for many other android bugs and limitations I have
> met. This is a bug, and I hope it would be fixed - in my case I have
> met it even not in my code, but in the 3rd party library I wanted to
> use - luckily it has GPL license and I could create a modified version
> that works on android for me with stale checking disabled.

> On Jan 20, 11:08 pm, tomgibara <tomgib...@hotmail.com> wrote:

> > Thanks for that workaround, I'll try it out. As I hinted in my
> > posting, I was too tired at the time to pursue it further and have
> > ignored the problem since then (side stepping it mostly by not reusing
> >HttpClientinstances) so I'm glad you took the time to post your
> > workaround.

> > The docs for the method state:

> > Defines whether stale connection check is to be used. Disabling stale
> > connection check may result in slight performance improvement at the
> > risk of getting an I/O error when executing a request over a
> > connection that has been closed at the server side.

> > I presume this is referring to the situation when a server times-out a
> > 'kept-alive' HTTP session. I don't know how often that will happen
> > since I expect it depends on the behaviour of theHttpClientlibrary
> > code. Anyway, it's got to be better than the workaround I've been
> > using.

> > On Jan 19, 11:51 pm, fry <bender...@gmail.com> wrote:

> > > Hi! I had the same problem - the workaround is rather simple:

> > >httpclient.getHttpConnectionManager().getParams().setStaleCheckingEnabled( false);

> > > On Dec 31 2007, 1:41 am, tomgibara <tomgib...@hotmail.com> wrote:

> > > > Phew... this has taken me many many hours to track down, mostly
> > > > because I stumbled across it in the middle of some dense resource
> > > > management code - and the problem is actually very far from there...

> > > > Here's a test method (with a trivial subsidiary method) that makes two
> > > > sequential requests to the same server using two different GetMethod
> > > > objects sharing oneHttpClientobject - I presume a very common
> > > > situation:

> > > >     private void testSequentialGet(String url) {
> > > >        HttpClientclient = newHttpClient();
> > > >         byte[] buffer = new byte[8192];
> > > >         try {

> > > >             GetMethod get1 = new GetMethod(url);
> > > >             try {
> > > >                 int status = client.executeMethod(get1);
> > > >                 Log.i("test", "Status for " + url + " (1) = " + status);
> > > >                 long read = exhaust(get1.getResponseBodyAsStream(),
> > > > buffer);
> > > >                 Log.i("test", "Bytes read for " + url + " (1) = " +
> > > > read);
> > > >             } finally {
> > > >                 get1.releaseConnection();
> > > >             }

> > > >             GetMethod get2 = new GetMethod(url);
> > > >             try {
> > > >                 int status = client.executeMethod(get2);
> > > >                 Log.i("test", "Status for " + url + " (2) = " + status);
> > > >                 long read = exhaust(get2.getResponseBodyAsStream(),
> > > > buffer);
> > > >                 Log.i("test", "Bytes read for " + url + " (2) = " +
> > > > read);
> > > >             } finally {
> > > >                 get2.releaseConnection();
> > > >             }
> > > >         } catch (HttpException e) {
> > > >             Log.i("test", "Test of " + url + " failed with an HTTP
> > > > exception.", e);
> > > >         } catch (IOException e) {
> > > >             Log.i("test", "Test of " + url + " failed with an IO
> > > > exception.", e);
> > > >         }
> > > >     }

> > > >     private static long exhaust(final InputStream in, byte[] buffer)
> > > > throws IOException {
> > > >         long read = 0L;
> > > >         try {
> > > >             for (int r = 0; r >= 0; r = in.read(buffer)) read += r;
> > > >         } finally {
> > > >             try {
> > > >                 in.close();
> > > >             } catch (IOException e) { }
> > > >         }
> > > >         return read;
> > > >     }

> > > > We can call this method (using the latest version of the emulator to-
> > > > date: m3-rc37) with a number of different URLs:

> > > > testSequentialGet("http://www.google.com");
> > > > testSequentialGet("http://www.apache.org");
> > > > testSequentialGet("http://www.microsoft.com");

> > > > and the resulting output in the log is:

> > > > I/test(656): Status forhttp://www.google.com(1) = 200
> > > > I/test(656): Bytes read forhttp://www.google.com(1) = 5424
> > > > I/test(656): Status forhttp://www.google.com(2) = 200
> > > > I/test(656): Bytes read forhttp://www.google.com(2) = 5424

> > > > I/test(656): Status forhttp://www.apache.org(1) = 200
> > > > I/test(656): Bytes read forhttp://www.apache.org(1) = 17409
> > > > I/test(656): Test ofhttp://www.apache.orgfailedwithanIO
> > > > exception.

> > > > I/test(656): Test ofhttp://www.microsoft.comfailedwithanIO
> > > > exception.
> > > > I/test(656): java.io.InterruptedIOException: Read timed out

> > > > Repeated requests to Google work as expected. The first request to
> > > > Apache (running a development version of the Apache webserver)
> > > > succeeds but the second request fails. The first request to Microsoft
> > > > (running IIS7) fails. These are, as far as I can confirm, entirely
> > > > reproducible exceptions, and I don't think I'm making any mistakes in
> > > > my use of the JakartaHttpClientlibrary. Nor am I behind a proxy
> > > > server.

> > > > Anecdotally, I think that the problems may be related to HTTP/1.1 Keep
> > > > Alives. I have three pieces of evidence for this. Firstly, disabling
> > > > Keep Alives on my local development server (which is where I first
> > > > encountered the problem) seemed to remove the exception. Secondly, I
> > > > briefly looked online for a popular site that runs with Keep Alives
> > > > disabled, I found Slashdot (http://slashdot.org) which runs in this
> > > > way (on an Apache webserver); repeated requests to the /. homepage do
> > > > not trigger an exception. Thirdly, the exception itself (which I don't
> > > > have the motivation to investigate further at this time) is the same
> > > > in every case and looks like this:

> > > > I/test(680):     at
> > > > org.apache.harmony.luni.platform.OSFileSystem.readImpl(Native Method)
> > > > I/test(680):     at
> > > > org.apache.harmony.luni.platform.OSFileSystem.read(OSFileSystem.java:
> > > > 150)
> > > > I/test(680):     at java.io.FileInputStream.read(FileInputStream.java:
> > > > 306)
> > > > I/test(680):     at
> > > > java.io.BufferedInputStream.fillbuf(BufferedInputStream.java:173)
> > > > I/test(680):     at
> > > > java.io.BufferedInputStream.read(BufferedInputStream.java:228)
> > > > I/test(680):     at
> > > > org.apache.commons.httpclient.HttpConnection.isStale(HttpConnection.java:
> > > > 509)
> > > > I/test(680):     at
> > > > org.apache.commons.httpclient.HttpConnection.closeIfStale(HttpConnection.ja va:
> > > > 434)
> > > > I/test(680):     at
> > > > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMetho dDirector.java:
> > > > 381)
> > > > I/test(680):     at
> > > > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDi rector.java:
> > > > 170)
> > > > I/test(680):     at
> > > > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> > > > 398)
> > > > I/test(680):     at
> > > > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> > > > 326)

> > > > Checking forstaleconnections might have some interaction with
> > > > persistent connections?

> > > > There are numerous plausible workarounds; if this bug is not to be
> > > > fixed soon, I welcome any advice on the best workaround to adopt since
> > > > I don't have a handle on its scope.

> I really hope this is fixed soon, java's URLConnection is such a dog
> of an implementation, not being able to handle timeouts is such a
> pain.

> I had no success with .setStaleCheckingEnabled(false);

> Craig.

> On Jan 21, 11:41 pm, fry <bender...@gmail.com> wrote:

> > I meant it is simple that it is just one line code, but it was not
> > really simple to find it :)

> > As for the disabling StaleChecking, currently I really do not care if
> > it would bring some instability in some cases - for me it is more than
> > enough that it just works at current moment - I could not find even
> > such workarounds for many other android bugs and limitations I have
> > met. This is a bug, and I hope it would be fixed - in my case I have
> > met it even not in my code, but in the 3rd party library I wanted to
> > use - luckily it has GPL license and I could create a modified version
> > that works on android for me with stale checking disabled.

> > On Jan 20, 11:08 pm, tomgibara <tomgib...@hotmail.com> wrote:

> > > Thanks for that workaround, I'll try it out. As I hinted in my
> > > posting, I was too tired at the time to pursue it further and have
> > > ignored the problem since then (side stepping it mostly by not reusing
> > >HttpClientinstances) so I'm glad you took the time to post your
> > > workaround.

> > > The docs for the method state:

> > > Defines whether stale connection check is to be used. Disabling stale
> > > connection check may result in slight performance improvement at the
> > > risk of getting an I/O error when executing a request over a
> > > connection that has been closed at the server side.

> > > I presume this is referring to the situation when a server times-out a
> > > 'kept-alive' HTTP session. I don't know how often that will happen
> > > since I expect it depends on the behaviour of theHttpClientlibrary
> > > code. Anyway, it's got to be better than the workaround I've been
> > > using.

> > > On Jan 19, 11:51 pm, fry <bender...@gmail.com> wrote:

> > > > Hi! I had the same problem - the workaround is rather simple:

> > > >httpclient.getHttpConnectionManager().getParams().setStaleCheckingEnabled( false);

> > > > On Dec 31 2007, 1:41 am, tomgibara <tomgib...@hotmail.com> wrote:

> > > > > Phew... this has taken me many many hours to track down, mostly
> > > > > because I stumbled across it in the middle of some dense resource
> > > > > management code - and the problem is actually very far from there...

> > > > > Here's a test method (with a trivial subsidiary method) that makes two
> > > > > sequential requests to the same server using two different GetMethod
> > > > > objects sharing oneHttpClientobject - I presume a very common
> > > > > situation:

> > > > >     private void testSequentialGet(String url) {
> > > > >        HttpClientclient = newHttpClient();
> > > > >         byte[] buffer = new byte[8192];
> > > > >         try {

> > > > >             GetMethod get1 = new GetMethod(url);
> > > > >             try {
> > > > >                 int status = client.executeMethod(get1);
> > > > >                 Log.i("test", "Status for " + url + " (1) = " + status);
> > > > >                 long read = exhaust(get1.getResponseBodyAsStream(),
> > > > > buffer);
> > > > >                 Log.i("test", "Bytes read for " + url + " (1) = " +
> > > > > read);
> > > > >             } finally {
> > > > >                 get1.releaseConnection();
> > > > >             }

> > > > >             GetMethod get2 = new GetMethod(url);
> > > > >             try {
> > > > >                 int status = client.executeMethod(get2);
> > > > >                 Log.i("test", "Status for " + url + " (2) = " + status);
> > > > >                 long read = exhaust(get2.getResponseBodyAsStream(),
> > > > > buffer);
> > > > >                 Log.i("test", "Bytes read for " + url + " (2) = " +
> > > > > read);
> > > > >             } finally {
> > > > >                 get2.releaseConnection();
> > > > >             }
> > > > >         } catch (HttpException e) {
> > > > >             Log.i("test", "Test of " + url + " failed with an HTTP
> > > > > exception.", e);
> > > > >         } catch (IOException e) {
> > > > >             Log.i("test", "Test of " + url + " failed with an IO
> > > > > exception.", e);
> > > > >         }
> > > > >     }

> > > > >     private static long exhaust(final InputStream in, byte[] buffer)
> > > > > throws IOException {
> > > > >         long read = 0L;
> > > > >         try {
> > > > >             for (int r = 0; r >= 0; r = in.read(buffer)) read += r;
> > > > >         } finally {
> > > > >             try {
> > > > >                 in.close();
> > > > >             } catch (IOException e) { }
> > > > >         }
> > > > >         return read;
> > > > >     }

> > > > > We can call this method (using the latest version of the emulator to-
> > > > > date: m3-rc37) with a number of different URLs:

> > > > > testSequentialGet("http://www.google.com");
> > > > > testSequentialGet("http://www.apache.org");
> > > > > testSequentialGet("http://www.microsoft.com");

> > > > > and the resulting output in the log is:

> > > > > I/test(656): Status forhttp://www.google.com(1) = 200
> > > > > I/test(656): Bytes read forhttp://www.google.com(1) = 5424
> > > > > I/test(656): Status forhttp://www.google.com(2) = 200
> > > > > I/test(656): Bytes read forhttp://www.google.com(2) = 5424

> > > > > I/test(656): Status forhttp://www.apache.org(1) = 200
> > > > > I/test(656): Bytes read forhttp://www.apache.org(1) = 17409
> > > > > I/test(656): Test ofhttp://www.apache.orgfailedwithanIO
> > > > > exception.

> > > > > I/test(656): Test ofhttp://www.microsoft.comfailedwithanIO
> > > > > exception.
> > > > > I/test(656): java.io.InterruptedIOException: Read timed out

> > > > > Repeated requests to Google work as expected. The first request to
> > > > > Apache (running a development version of the Apache webserver)
> > > > > succeeds but the second request fails. The first request to Microsoft
> > > > > (running IIS7) fails. These are, as far as I can confirm, entirely
> > > > > reproducible exceptions, and I don't think I'm making any mistakes in
> > > > > my use of the JakartaHttpClientlibrary. Nor am I behind a proxy
> > > > > server.

> > > > > Anecdotally, I think that the problems may be related to HTTP/1.1 Keep
> > > > > Alives. I have three pieces of evidence for this. Firstly, disabling
> > > > > Keep Alives on my local development server (which is where I first
> > > > > encountered the problem) seemed to remove the exception. Secondly, I
> > > > > briefly looked online for a popular site that runs with Keep Alives
> > > > > disabled, I found Slashdot (http://slashdot.org) which runs in this
> > > > > way (on an Apache webserver); repeated requests to the /. homepage do
> > > > > not trigger an exception. Thirdly, the exception itself (which I don't
> > > > > have the motivation to investigate further at this time) is the same
> > > > > in every case and looks like this:

> > > > > I/test(680):     at
> > > > > org.apache.harmony.luni.platform.OSFileSystem.readImpl(Native Method)
> > > > > I/test(680):     at
> > > > > org.apache.harmony.luni.platform.OSFileSystem.read(OSFileSystem.java:
> > > > > 150)
> > > > > I/test(680):     at java.io.FileInputStream.read(FileInputStream.java:
> > > > > 306)
> > > > > I/test(680):     at
> > > > > java.io.BufferedInputStream.fillbuf(BufferedInputStream.java:173)
> > > > > I/test(680):     at
> > > > > java.io.BufferedInputStream.read(BufferedInputStream.java:228)
> > > > > I/test(680):     at
> > > > > org.apache.commons.httpclient.HttpConnection.isStale(HttpConnection.java:
> > > > > 509)
> > > > > I/test(680):     at
> > > > > org.apache.commons.httpclient.HttpConnection.closeIfStale(HttpConnection.ja va:
> > > > > 434)
> > > > > I/test(680):     at
> > > > > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMetho dDirector.java:
> > > > > 381)
> > > > > I/test(680):     at
> > > > > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDi rector.java:
> > > > > 170)
> > > > > I/test(680):     at
> > > > > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> > > > > 398)
> > > > > I/test(680):     at
> > > > > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:
> > > > > 326)

> > > > > Checking forstaleconnections might have some interaction with
> > > > > persistent

> Do you have the same exception stack trace? I was able to find the
> workaround because I saw the following line in the stack trace:

> I/test(680):
> atorg.apache.commons.httpclient.HttpConnection.isStale(HttpConnection.java:
> 509)

> You can see that the exception came from the isStale() call and went
> deeper to some kind of file system native call problem. So this gave
> me the idea, that if I would switch the stale checking off, this
> method would not be called and problem would not appear - and luckily
> this helped. Probably you have another kind of problem, or after
> switching off stale checking another problem showed itself, or you are
> switching it off not for allhttpclientobjects.

> I/test(680):     at
> org.apache.harmony.luni.platform.OSFileSystem.readImpl(Native Method)
> I/test(680):     at
> org.apache.harmony.luni.platform.OSFileSystem.read(OSFileSystem.java:
> 150)
> I/test(680):     at java.io.FileInputStream.read(FileInputStream.java:
> 306)
> I/test(680):     at
> java.io.BufferedInputStream.fillbuf(BufferedInputStream.java:173)
> I/test(680):     at
> java.io.BufferedInputStream.read(BufferedInputStream.java:228)
> I/test(680):
> atorg.apache.commons.httpclient.HttpConnection.isStale(HttpConnection.java:
> 509)

> On Jan 24, 6:46 am, baker <craigbba...@gmail.com> wrote:

> > I really hope this is fixed soon, java's URLConnection is such a dog
> > of an implementation, not being able to handle timeouts is such a
> > pain.

> > I had no success with .setStaleCheckingEnabled(false);

> > Craig.

> > On Jan 21, 11:41 pm, fry <bender...@gmail.com> wrote:

> > > I meant it is simple that it is just one line code, but it was not
> > > really simple to find it :)

> > > As for the disabling StaleChecking, currently I really do not care if
> > > it would bring some instability in some cases - for me it is more than
> > > enough that it just works at current moment - I could not find even
> > > such workarounds for many other android bugs and limitations I have
> > > met. This is a bug, and I hope it would be fixed - in my case I have
> > > met it even not in my code, but in the 3rd party library I wanted to
> > > use - luckily it has GPL license and I could create a modified version
> > > that works on android for me with stale checking disabled.

> > > On Jan 20, 11:08 pm, tomgibara <tomgib...@hotmail.com> wrote:

> > > > Thanks for that workaround, I'll try it out. As I hinted in my
> > > > posting, I was too tired at the time to pursue it further and have
> > > > ignored the problem since then (side stepping it mostly by not reusing
> > > >HttpClientinstances) so I'm glad you took the time to post your
> > > > workaround.

> > > > The docs for the method state:

> > > > Defines whether stale connection check is to be used. Disabling stale
> > > > connection check may result in slight performance improvement at the
> > > > risk of getting an I/O error when executing a request over a
> > > > connection that has been closed at the server side.

> > > > I presume this is referring to the situation when a server times-out a
> > > > 'kept-alive' HTTP session. I don't know how often that will happen
> > > > since I expect it depends on the behaviour of theHttpClientlibrary
> > > > code. Anyway, it's got to be better than the workaround I've been
> > > > using.

> > > > On Jan 19, 11:51 pm, fry <bender...@gmail.com> wrote:

> > > > > Hi! I had the same problem - the workaround is rather simple:

> > > > >httpclient.getHttpConnectionManager().getParams().setStaleCheckingEnabled( false);

> > > > > On Dec 31 2007, 1:41 am, tomgibara <tomgib...@hotmail.com> wrote:

> > > > > > Phew... this has taken me many many hours to track down, mostly
> > > > > > because I stumbled across it in the middle of some dense resource
> > > > > > management code - and the problem is actually very far from there...

> > > > > > Here's a test method (with a trivial subsidiary method) that makes two
> > > > > > sequential requests to the same server using two different GetMethod
> > > > > > objects sharing oneHttpClientobject - I presume a very common
> > > > > > situation:

> > > > > >     private void testSequentialGet(String url) {
> > > > > >        HttpClientclient = newHttpClient();
> > > > > >         byte[] buffer = new byte[8192];
> > > > > >         try {

> > > > > >             GetMethod get1 = new GetMethod(url);
> > > > > >             try {
> > > > > >                 int status = client.executeMethod(get1);
> > > > > >                 Log.i("test", "Status for " + url + " (1) = " + status);
> > > > > >                 long read = exhaust(get1.getResponseBodyAsStream(),
> > > > > > buffer);
> > > > > >                 Log.i("test", "Bytes read for " + url + " (1) = " +
> > > > > > read);
> > > > > >             } finally {
> > > > > >                 get1.releaseConnection();
> > > > > >             }

> > > > > >             GetMethod get2 = new GetMethod(url);
> > > > > >             try {
> > > > > >                 int status = client.executeMethod(get2);
> > > > > >                 Log.i("test", "Status for " + url + " (2) = " + status);
> > > > > >                 long read = exhaust(get2.getResponseBodyAsStream(),
> > > > > > buffer);
> > > > > >                 Log.i("test", "Bytes read for " + url + " (2) = " +
> > > > > > read);
> > > > > >             } finally {
> > > > > >                 get2.releaseConnection();
> > > > > >             }
> > > > > >         } catch (HttpException e) {
> > > > > >             Log.i("test", "Test of " + url + " failed with an HTTP
> > > > > > exception.", e);
> > > > > >         } catch (IOException e) {
> > > > > >             Log.i("test", "Test of " + url + " failed with an IO
> > > > > > exception.", e);
> > > > > >         }
> > > > > >     }

> > > > > >     private static long exhaust(final InputStream in, byte[] buffer)
> > > > > > throws IOException {
> > > > > >         long read = 0L;
> > > > > >         try {
> > > > > >             for (int r = 0; r >= 0; r = in.read(buffer)) read += r;
> > > > > >         } finally {
> > > > > >             try {
> > > > > >                 in.close();
> > > > > >             } catch (IOException e) { }
> > > > > >         }
> > > > > >         return read;
> > > > > >     }

> > > > > > We can call this method (using the latest version of the emulator to-
> > > > > > date: m3-rc37) with a number of different URLs:

> > > > > > testSequentialGet("http://www.google.com");
> > > > > > testSequentialGet("http://www.apache.org");
> > > > > > testSequentialGet("http://www.microsoft.com");

> > > > > > and the resulting output in the log is:

> > > > > > I/test(656): Status forhttp://www.google.com(1) = 200
> > > > > > I/test(656): Bytes read forhttp://www.google.com(1) = 5424
> > > > > > I/test(656): Status forhttp://www.google.com(2) = 200
> > > > > > I/test(656): Bytes read forhttp://www.google.com(2) = 5424

> > > > > > I/test(656): Status forhttp://www.apache.org(1) = 200
> > > > > > I/test(656): Bytes read forhttp://www.apache.org(1) = 17409
> > > > > > I/test(656): Test ofhttp://www.apache.orgfailedwithanIO
> > > > > > exception.

> > > > > > I/test(656): Test ofhttp://www.microsoft.comfailedwithanIO
> > > > > > exception.
> > > > > > I/test(656): java.io.InterruptedIOException: Read timed out

> > > > > > Repeated requests to Google work as expected. The first request to
> > > > > > Apache (running a development version of the Apache webserver)
> > > > > > succeeds but the second request fails. The first request to Microsoft
> > > > > > (running IIS7) fails. These are, as far as I can confirm, entirely
> > > > > > reproducible exceptions, and I don't think I'm making any mistakes in
> > > > > > my use of the JakartaHttpClientlibrary. Nor am I behind a proxy
> > > > > > server.

> > > > > > Anecdotally, I think that the problems may be related to HTTP/1.1 Keep
> > > > > > Alives. I have three pieces of evidence for this. Firstly, disabling
> > > > > > Keep Alives on my local development server (which is where I first
> > > > > > encountered the problem) seemed to remove the exception. Secondly, I
> > > > > > briefly looked online for a popular site that runs with Keep Alives
> > > > > > disabled, I found Slashdot (http://slashdot.org) which runs in this
> > > > > > way (on an Apache webserver); repeated requests to the /. homepage do
> > > > > > not trigger an exception. Thirdly, the exception itself (which I don't
> > > > > > have the motivation to investigate further at this time) is the same
> > > > > > in every case and looks like this:

> > > > > > I/test(680):     at
> > > > > > org.apache.harmony.luni.platform.OSFileSystem.readImpl(Native Method)
> > > > > > I/test(680):     at
> > > > > > org.apache.harmony.luni.platform.OSFileSystem.read(OSFileSystem.java:
> > > > > > 150)
> > > > > > I/test(680):     at java.io.FileInputStream.read(FileInputStream.java:
> > > > > > 306)
> > > > > > I/test(680):     at
> > > > > > java.io.BufferedInputStream.fillbuf(BufferedInputStream.java:173)
> > > > > > I/test(680):     at