unexpected end of stream error on download? [duplicate]

Question

Possible Duplicate:
Android:“Unexpected end of stream” exception downloading large files

I'm downloding a file of approx. 5MB using HttpURLConnection but half way during the downlod i get an "unexpected end of stream" error at this line of my code:

                     while ((count = input.read(data)) > 0) {

Here is the LOG:

11-20 16:05:55.749: ERROR/PRINTSTACK(3425): STACK:unexpected end of stream
11-20 16:05:55.749: WARN/System.err(3425): java.io.IOException: unexpected end of stream
11-20 16:05:55.749: WARN/System.err(3425):     at org.apache.harmony.luni.internal.net.www.protocol.http.FixedLengthInputStream.read(FixedLengthInputStream.java:47)
11-20 16:05:55.749: WARN/System.err(3425):     at java.io.BufferedInputStream.read(BufferedInputStream.java:319)
11-20 16:05:55.749: WARN/System.err(3425):     at java.io.FilterInputStream.read(FilterInputStream.java:133)
11-20 16:05:55.759: WARN/System.err(3425):     at com.conjure.skiproj.DownloadService$Job.process(DownloadService.java:265)
11-20 16:05:55.759: WARN/System.err(3425):     at com.conjure.skiproj.DownloadService$1.run(DownloadService.java:193)
11-20 16:05:55.759: WARN/System.err(3425):     at java.lang.Thread.run(Thread.java:1019)

Help !!1

EDIT: more info on the code setting up the inputstream:

    HttpURLConnection conexion = (HttpURLConnection)url.openConnection();
                        conexion.setRequestMethod("GET");
                        conexion.setReadTimeout(20000);
                        conexion.connect();
                        File file = new File(root.getAbsolutePath()+"/", fileName);

                             int lenghtOfFile = conexion.getContentLength();

                             InputStream input = new BufferedInputStream(url.openStream());

                             OutputStream output = new FileOutputStream(file);

                             byte data[] = new byte[8192];
...........................

EDIT 2: Got a new error IndexOutOfBoundsException on 25% of download on the following line:

  output.write(data, 0, count);

LOG below:

11-20 17:47:02.311: ERROR/totaltotal(303): 24
11-20 17:47:02.311: INFO/System.out(303): countcountcount:4332
11-20 17:47:02.330: ERROR/totaltotal(303): 24
11-20 17:47:02.330: INFO/System.out(303): countcountcount:2904
11-20 17:47:02.330: ERROR/totaltotal(303): 25
11-20 17:47:02.330: INFO/System.out(303): countcountcount:1452
11-20 17:47:02.330: ERROR/totaltotal(303): 25
11-20 17:47:02.650: INFO/System.out(303): countcountcount:4356
11-20 17:47:02.650: ERROR/totaltotal(303): 25
11-20 17:47:02.650: INFO/System.out(303): countcountcount:-1
11-20 17:47:02.660: ERROR/totaltotal(303): 25
11-20 17:47:02.892: DEBUG/dalvikvm(303): GC_FOR_MALLOC freed 10770 objects / 490896 bytes in 143ms
11-20 17:47:03.060: ERROR/PRINTSTACK(303): STACK:Arguments out of bounds
11-20 17:47:03.060: WARN/System.err(303): java.lang.IndexOutOfBoundsException: Arguments out of bounds
11-20 17:47:03.070: WARN/System.err(303):     at java.io.FileOutputStream.write(FileOutputStream.java:288)
11-20 17:47:03.080: WARN/System.err(303):     at com.conjure.skiproj.DownloadService$Job.process(DownloadService.java:275)
11-20 17:47:03.080: WARN/System.err(303):     at com.conjure.skiproj.DownloadService$1.run(DownloadService.java:191)
11-20 17:47:03.080: WARN/System.err(303):     at java.lang.Thread.run(Thread.java:1096)

EDIT 3: I traced the error back to FixedLengthInputStream class and then further back to AbstractHttpInputStream class in where there is this method:

/**
             * Calls abort on the cache entry and disconnects the socket. This
             * should be invoked when the connection is closed unexpectedly to
             * invalidate the cache entry and to prevent the HTTP connection from
             * being reused. HTTP messages are sent in serial so whenever a message
             * cannot be read to completion, subsequent messages cannot be read
             * either and the connection must be discarded.
             *
             * <p>An earlier implementation skipped the remaining bytes, but this
             * requires that the entire transfer be completed. If the intention was
             * to cancel the transfer, closing the connection is the only solution.
             */
            protected final void unexpectedEndOfInput() {
                if (cacheRequest != null) {
                    cacheRequest.abort();
                }
                httpURLConnection.releaseSocket(false);
            }

So it seems that in the case of an Http message error the whole download stream is canceled.

Picturesque

I doubt it will help but try using InputStream input = conexion.getInputStream(); instead of using url.openStream() to create a BufferedInputStream. – Ibby

just tried this, it doesn't work!! – Picturesque

ANYONE HAS ANY IDEA ON HOW TO GO ABOUT SOLVING THIS, OR ANY HINTS OR DIRECTIONS !!! – Picturesque

Answer 1

That exception is thrown by FixedLengthInputStream when the expected number of bytes (usually set in the content-length header of the response) is larger than the actual data in the response. Check that the content-length header is correct. (If you're supplying your own value for the content length, make sure it is correct.)

It would help to see your code that sets up the input stream.

Feuilleton

Just edited my question. Provided some more info. – Picturesque

It still looks like the content-length header is wrong. Also, if all you're doing is reading the data and dumping it into a file, you don't need to wrap the input stream in a BufferedInputStream. You're already using your own buffer and double-buffering like that just adds overhead. It shouldn't affect anything, but try getting rid of that wrapper. – Feuilleton

the content-length is fine, i'm getting the correct size of the file which 5171472 (~5.2MB) – Picturesque

it's weird because it stops only between 50% - 80% of the downloading process – Picturesque

@user967232 - Very weird. If you repeat the same download, does it get to different points in the process before failing? Could a proxy or something be closing the download stream prematurely? – Feuilleton

yes it does, just now it stopped at 93%. Before that it stopped at 76%... so it's like this !! – Picturesque

@user967232 - Is this on a real device or an emulator? If on a real device, try running on an emulator. If the problem goes away, it's time to stop looking at the code and start looking at connectivity issues or other factors that may interrupt the download. – Feuilleton

it doesn't work on both of them(emulator and real device). I just go a new error now see my edited question for more info! – Picturesque

@user967232 - From the stack trace, it seems that the index out of bounds exception is happening after count == -1. There's got to be a problem somewhere else in your code. – Feuilleton

this error happened only once.. and i fixed it. But i'm still getting the "unexpected end of stream" error – Picturesque

@user967232 - I'm out of ideas here. Maybe someone else can chime in. – Feuilleton

I get this exception on slow internet connection(<100Kbps). – Ladawnladd

Answer 2

A count of 0 is allowable as far as I understand it in case of network problem. Try...

while ((count = input.read(data)) != -1) {
    if (count != 0) {
        ...
    }
}

Ibby

I don't think 0 should be allowed for here. From the docs for InputStream: If the length of b is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at the end of the file, the value -1 is returned; otherwise, at least one byte is read and stored into b. – Feuilleton

@Ted: OK, I agree with you from what the documentation says but I had an issue with one of my beta-testers getting failures when my app was downloading some files. A Java programmer himself, he suggested I structure my code as in my answer above. He suggested that a return of 0 bytes could happen when associated with a network stream. It fixed his download failures. Besides, in this case it's a moot point as it didn't fix the OP's problem. – Ibby