Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.2.0, 2.3.0
-
None
-
Tested on a Motorola Atrix HD(Android 4.1.2) as well as a Samsung Galaxy S3(Android 4.1.1)
Description
When uploading pictures using the File Transfer function on android, the first picture will upload fine. Then the second upload will give the following error:
01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from connection.
01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
01-21 13:48:02.545: W/FileTransfer(8894): at libcore.io.Streams.readAsciiLine(Streams.java:203)
01-21 13:48:02.545: W/FileTransfer(8894): at libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
01-21 13:48:02.545: W/FileTransfer(8894): at libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
01-21 13:48:02.545: W/FileTransfer(8894): at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
01-21 13:48:02.545: W/FileTransfer(8894): at libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
01-21 13:48:02.545: W/FileTransfer(8894): at org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
01-21 13:48:02.545: W/FileTransfer(8894): at org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
01-21 13:48:02.545: W/FileTransfer(8894): at org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
01-21 13:48:02.545: W/FileTransfer(8894): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.545: W/FileTransfer(8894): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.545: W/FileTransfer(8894): at java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894):
01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
01-21 13:48:02.555: E/FileTransfer(8894): at libcore.io.IoBridge.sendto(IoBridge.java:475)
01-21 13:48:02.555: E/FileTransfer(8894): at java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
01-21 13:48:02.555: E/FileTransfer(8894): at java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
01-21 13:48:02.555: E/FileTransfer(8894): at java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
01-21 13:48:02.555: E/FileTransfer(8894): at libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
01-21 13:48:02.555: E/FileTransfer(8894): at java.io.DataOutputStream.write(DataOutputStream.java:98)
01-21 13:48:02.555: E/FileTransfer(8894): at org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
01-21 13:48:02.555: E/FileTransfer(8894): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.555: E/FileTransfer(8894): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.555: E/FileTransfer(8894): at java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894): Caused by: libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at libcore.io.Posix.sendtoBytes(Native Method)
01-21 13:48:02.555: E/FileTransfer(8894): at libcore.io.Posix.sendto(Posix.java:146)
01-21 13:48:02.555: E/FileTransfer(8894): at libcore.io.BlockGuardOs.sendto(BlockGuardOs.java:177)
01-21 13:48:02.555: E/FileTransfer(8894): at libcore.io.IoBridge.sendto(IoBridge.java:473)
01-21 13:48:02.555: E/FileTransfer(8894): ... 9 more
01-21 13:48:02.575: D/CordovaLog(8894): error:
01-21 13:48:02.575: I/Web Console(8894): error:
{"code":3,"source":"file:///storage/sdcard0/Android/data/com.hockeycommunity.hc_app/cache/resize.jpg?1358804880392","target":"http://xxx.xxx.xxx/api/photo_uploads/create?version=2&api_key=xxxxxxx&source=androidapp-2.2.1","http_status":null}at file:///android_asset/www/interfaces/int.upload_picture.js:28
Then the next picture will upload fine, and the next one will get the same error code. Every other picture upload works.
Attachments
Attachments
- cordova-2.4.0rc1.jar
- 233 kB
- Andrew Grieve
Issue Links
- is cloned by
-
CB-4479 phonegap 2.9 strange (repeated upload) problem
- Closed
- is duplicated by
-
CB-4479 phonegap 2.9 strange (repeated upload) problem
- Closed
-
CB-5635 File Transfer of picture fails on every Second picture
- Closed
-
CB-6034 File transfer fails every other attempt on Android
- Closed
- is related to
-
CB-5799 Update to OK HTTP 1.3
- Closed
- relates to
-
CB-7326 File upload fails in WP8
- Closed
Activity
Sure:
uploadPicture_new = function () {};
uploadPicture_new.prototype = {
constructor: uploadPicture_new,
transfert : function(params,fct_api,option) {
var ft = new FileTransfer(),
parameters=params,
uploadcomplete=0,
progress = 0,
options = new FileUploadOptions();
//even if not used, it is mandatory
options.fileKey="photo";
options.fileName=imageCaptured.substr(imageCaptured.lastIndexOf('/')+1);
options.mimeType="image/jpeg";
// For true progress
ft.onprogress = function(progressEvent) {
if (progressEvent.lengthComputable)
else
{ loadingStatus.increment(); } };
//Not possible to use Oauth in this case so API_KEY
ft.upload(imageCaptured, Base+"photo_uploads/create,uploadedProfilePicture,function(message)
, options);
function uploadedProfilePicture(information_back){
var param_photo="";
Image_Upload_Id=information_back.response;
console.log(Image_Upload_Id);
if (Image_Upload_Id != undefined && Image_Upload_Id != "")
fct_api.send(parameters+param_photo,true);
};
}
}
Heh, first result when searching for the error is another Cordova user with the same problem .
Yea I've seen one fix that works with HTTPS, but nothing so far for regular ol http
Soo... pretty hard bug to work on because it's not easy to reproduce. But, looking at the line that's throwing an exception, I have a theory as to what's wrong, and I'm wondering if you'd be able to try it out to see if it fixes the problem.
On line 372 of FileTransfer.java, I think:
dos.write(buffer, 0, bufferSize);
should say:
dos.write(buffer, 0, bytesRead);
I'll likely commit this anyways, since it's a pretty obvious bug, but would also love to know if it fixes your app.
Hmm, I'm guessing you're using cordova in the form a .jar then? try this (attaching jar with the change to this bug)
Hey Andrew, that did not fix the error, it occurred again on the second photo upload.
01-28 10:04:24.392: W/FileTransfer(25314): Error getting HTTP status code from connection.
01-28 10:04:24.392: W/FileTransfer(25314): java.io.EOFException
01-28 10:04:24.392: W/FileTransfer(25314): at libcore.io.Streams.readAsciiLine(Streams.java:203)
01-28 10:04:24.392: W/FileTransfer(25314): at libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
01-28 10:04:24.392: W/FileTransfer(25314): at libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
01-28 10:04:24.392: W/FileTransfer(25314): at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
01-28 10:04:24.392: W/FileTransfer(25314): at libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
01-28 10:04:24.392: W/FileTransfer(25314): at org.apache.cordova.FileTransfer$1.run(FileTransfer.java:399)
01-28 10:04:24.392: W/FileTransfer(25314): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-28 10:04:24.392: W/FileTransfer(25314): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-28 10:04:24.392: W/FileTransfer(25314): at java.lang.Thread.run(Thread.java:856)
01-28 10:04:24.392: E/FileTransfer(25314):
01-28 10:04:24.392: E/FileTransfer(25314): java.io.EOFException
01-28 10:04:24.392: E/FileTransfer(25314): at libcore.io.Streams.readAsciiLine(Streams.java:203)
01-28 10:04:24.392: E/FileTransfer(25314): at libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
01-28 10:04:24.392: E/FileTransfer(25314): at libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
01-28 10:04:24.392: E/FileTransfer(25314): at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
01-28 10:04:24.392: E/FileTransfer(25314): at libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
01-28 10:04:24.392: E/FileTransfer(25314): at org.apache.cordova.FileTransfer$1.run(FileTransfer.java:399)
01-28 10:04:24.392: E/FileTransfer(25314): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-28 10:04:24.392: E/FileTransfer(25314): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-28 10:04:24.392: E/FileTransfer(25314): at java.lang.Thread.run(Thread.java:856)
Okay, did submit the one bugfix anyways:
Also added a log statement so that we'll know how much of the file was uploaded when the exception happens. From your stack trace, it looks like it happens after the file has finished uploading and it's reading the response headers.
I don't suppose you have any server logs that indicate what the error might be? I think what's happening is that server is closing the connection on us.
Actually, the thing is the server logs don't show anything at all! That's the strange part.
I'm having this exact same problem and can confirm the above. Here's where it fails for me. It is always the first progress update. Quick shout out for the progress update ability. Nice.
01-29 21:25:47.947: D/FileTransfer(31344): Uploaded 114688 of 623303 bytes
Error getting HTTP status code from connection.
Hey Drew! Thanks for helping out here! Is your stack trace the same?
Yeah, looks just like the one above. The only thing I can add is data from the recent progress logging. It gets through that first "Uploaded x of y bytes" and fails. But, only every other time. Other than that, it's all the same.
I'm really way in over my head here, but here's some lines from the error log that might be related:
[Tue Jan 29 15:16:09 2013] [notice] Graceful restart requested, doing restart
[Tue Jan 29 15:16:09 2013] [error] (9)Bad file descriptor: apr_socket_accept: (client socket)
[Tue Jan 29 15:16:10 2013] [notice] Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4 configured – resuming normal operations
Is there anything else from the logs that will help? Let me know and I'll get them ASAP.
Yeah, I don't know what to look for if there's nothing obvious.
Amrit, are you also hitting an Apache server? Possible the issue is httpd-specific.
There's now a new RC with the fix for bufferSize vs amountRead available here in case you want to double check that it's still broken:
https://dl.dropbox.com/u/6648754/cordova-2.4.0rc2/cordova-2.4.0rc2/cordova-android.zip
I'm currently out of ideas
I'm using a ruby on rails server running on heroku. I'll try that revision out later today, but I don't think that's the issue. The strangest part about this bug is it works every other time!
Just tried making my own sample app that does camera uploads, and I'm able to upload multiple images just fine. Ran it on the 4.0.3 emulator. Do you know if this bug repros on any of the emulators?
I can confirm that my code works on the emulator but fails on a Droid Razr M.
Sorry I never use the emulators since they're too slow. But I've tested on a Motorola Atrix HD and a Samsung Galaxy S3. I've found a workaround for this though, since it only fails every other upload, I just upload it again if it fails. Its working fine now from the users standpoint. Although its some ugly coding, it works!
ft.upload(imageCaptured, Base+"photo_uploads/create/test?version=2+ "&source="+source_app,uploadedProfilePicture,function(message){
console.log("error: " + JSON.stringify(message));
// Retry on failure
ft.upload(imageCaptured, Base+"photo_uploads/create/test?version=2+ "&source="+source_app,uploadedProfilePicture,function(message)
, options);
}, options);
I think the issue has something to do with the server I am uploading to, but it works fine on iOS with almost the exact same code.
I don't have either of those phones to test with .
Another stab-in-the-dark is that it's this bug:
http://stackoverflow.com/questions/3352424/httpurlconnection-openconnection-fails-second-time
You could try adding System.setProperty("http.keepAlive", "false"); to your start-up somewhere, and also delete the:
conn.setRequestProperty("Connection", "Keep-Alive");
line from FileTransfer.java
Eureka it works! That was a most excellent shot in the dark Andrew! Works fine now, no problems! Drew you should give it a shot. Many thanks for all your help Andrew!
Amrit, where did you implement System.setProperty("http.keepAlive", "false");?
Also, for obvious reasons, I'm going to keep from modifying core. Assuming this works, where do we go from here?
According to this post:
http://android-developers.blogspot.ca/2011/09/androids-http-clients.html
This bug is supposed to be fixed in Android 2.2. I guess some vendor versions still have the bug though .
One solution is to switch to HttpClient, another is to figure out which phones to disable connection: keep-alive for. Or maybe the problem is that we're explicitly setting the keep-alive header in FileTransfer.
Amrit, are you able to play around and see if just removing the explicit setting of the header works? Or maybe removing our call to InputStream.close()?
drewschmaltz I threw it in my main app.java file
public class staging extends DroidGap
{
@Override
public void onCreate(Bundle savedInstanceState)
}
I will try playing around and see what it was exactly
I tried just deleting setRequestProperty and my app crashed when I tried to upload a picture. Then I tried putting setRequestProperty back and simply add System.setProperty and my app uploaded one picture, but crashed on the second one. So the only way it works is when you delete the line from FileTransfer.java as well as add System.setProperty to you project.
Great! Thanks for the investigation Amrit!
Found another possibly-related SO question: http://stackoverflow.com/questions/12319194/android-httpurlconnection-throwing-eofexception
Right at the bottom they suggest that maybe toggling useChunkedMode will have an effect.
Another thing from the previous SO question suggested removing the .close() calls when reading the response, or removing the conn.disconnect() call right at the end of the method.
Are you able to see if these help?
I've tried the chunked mode already, didn't help. I'll give the other ones a shot
Tried it on a GS2 running 2.3.3, but unable to repro. Added a test to the mobile spec:
https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=commit;h=9872f7204175f595bb813bb121f6b1302775b7b2
Okay, got ahold of a GS3 4.1.1 and it also didn't repro.
I was using the mobilespec, which uploads to jitsu.com.
In order to debug further, I'm going to need better repro steps. e.g. a sample app I can run on my GS3 that shows the problem.
Sure thing, here's a staging version of our app. Feel free to upload as many pictures as you would like. I took out the fixes that made it work properly.
I think the sign in button will not work the first time, but you should be able to make an account or sign in with facebook. The sign in button will subsequently work if you do not log out.
okay, good news is I can reproduce it on my phone (N4) with your staging app. In order for me to try and fix the problem though, I'll need to be able to build it myself. If you don't want to share your source, building your app using cordova as a jar would work as well (that way I can replace the jar with my own version of FileTransfer)
Our investors policy would not allow me to share my code, I will build it using a jar.
Okay, after a bit of a marathon of trying random things, I've figure out that the problem goes away if I do any of the following:
1. Don't read the server response (we can actually read all but the last byte of it without it breaking...)
2. Turn off keep-alive
3. Turn off request streaming (don't call setFixedLengthStreamingMode nor setChunkedStreamingMode)
WTF Android!
Not sure what the way forward here is yet... Add an option to disable keep-alive maybe? Switch to HttpClient? Add an option to not read the response (seems dumb).
Yea, I hate how android has these little bugs that are such a pain. I'm going to release an update soon so I think I'm going with turning off keep-alive
I have the same problem and second uploaded file throw the same exception exception. I use Phonegap 2.3 and Asus Pad Nexus 7'.
Just wondering if this has been fixed in any recent versions of cordova.
@AndrewGrieve, I've found that the server isn't even registering the request when I get the client side error.
It's too late for 2.6 now, but expect to see some action here soon! (with our attempt to use the OkHttp library).
Okay, I've done some analysis on this, and this is what I'm seeing –
. The first request succeeds normally; the client requests that the connection remain open with "Connection: Keep-Alive" (explicit, but its the HTTP default anyway).
. Five seconds later, if there are no other requests, the server closes its end of the connection. That close isn't ACK'ed by the client, so it will still attempt to send data.
. The next request is sent on the same connection, and the server immediately sends RSTs to indicate that it will not accept it (as far as it is concerned, the connection should be closed)
. Rather than reopen the connection to retry the request, Android's HTTP Client rethrows the EOFException, and the second request simply fails. At this point, the client accepts that the connection is closed.
. A third request will open a new connection and succeed like the first.
Android's behaviour in this case is buggy; it shouldn't be up to the application code to explicitly retry the request.
(In fact, it looks like this was considered a bug (https://code.google.com/p/android/issues/detail?id=41576) and just fixed recently – but that's not a solution for anyone with an existing device)
This particular issue is not (yet) fixed in OkHttp, but I'm going to look at patching it there.
(We could also just wrap the FileTransfer request in a block that retries it once on failure, but I'd rather not do that. There may be other reasons that a request failed, and it may not be appropriate to retry a PUT/POST request if the request may have been received and processed)
OkHttp does solve this problem, but only for a more limited set of requests.
OkHttp can only automatically restart requests which have no body, or whose body is represented by a RetryableOutputStream (which internally buffers the entire body in a byte array)
The FileTransfer upload request doesn't generate a RetryableOutputStream, because we are using fixedLengthStreamingMode, specifically to avoid having to buffer the file in memory – files could be arbitrarily large. But file streams can also be restarted trivially, so there is no technical reason to exclude them.
I think I will probably end up making RetryableOutputStream an abstract class or an interface, and providing a new file-backed retryable output stream that can be restarted if the connection is closed.
Thats awesome Ian! Do you think you could post an RC with the RetryableOutputStream when you get it working?
I'll definitely push my branch so that you can try it yourself, as soon as I have it working.
FYI, I got Jesse Wilson to open an issue on OkHttp for this as well: https://github.com/square/okhttp/issues/137
I'll be tracking any progress that I make on the HTTP side there.
Okay, so I've merged in OkHttp, as of rev f38fec5b0 (see CB-2431). With that change, I can continue to upload pictures, even if the connection has been closed by the server. The failure is caught and automatically retried.
This is fixed in master, which should go out in 2.8.0 now (there's not as much testing time as I'd like to be able to get it into 2.7.0; I think that switching out the HTTP stack for all file transfers warrants a bit more testing).
We're on roughly a 1 month release cycle. 2.7 is slated for end of the week, so 2.8 should be first week of June.
I've tested my existing issue against 2.8.0 and I still get every other upload failing.
I look forward to some additional feedback on this.
The fix was in-fact included in 2.8.0. Are you still seeing the error as well?
I am actually starting a fresh app with 2.9 so I won't be able to test it quite yet.
Re-opened.
Jason - can you spell out what device & OS you're seeing this on?
Can you also verify whether it's an EOFException you're seeing in your logs.
Would it also be possible to let us know what server you're uploading to that will reproduce this?
To debug this, I'd need to be able to write an app with a giant button that performs a FileTransfer of a small file to your server. There definitely was a bug fixed in 2.8, so it could be that this issue has multiple things going on.
Certainly, this is an app running on Andrioid, (a Samsung Galaxy 3) the server is a Rails 3.2 server, with a PUT request (same happens when done as a POST btw.)
What I'll do is set up a standalone app that does an image capture and post / put to the server. Hopefully I can get this done within the next 24-36 hour or less.
I'll also setup a dedicated service to receive it, and provide the request details needed.
What I've done so far is try doing uploads via an existing Cordova app, and as a separate test curl, and a http request extension for Chrome called Postman, to check that uploading works outside the Cordova app.
These tests were repeated for 2.5(with a patch to allow PUT), and 2.8 both behave the same. All non Cordova tests pass, and the Cordova tests fail, as per the subject line, fault description of this ticket. No noticeable change with 2.8.
Anyway, I'll get that test environment isolated and post here when it's ready.
Thanks for your help
Quick additional note, (I'd already made a note of this originally.) the server never sees the failing posts
Can someone send me a demo project for this so we don't have to re-invent the wheel? We have a Samsung Galaxy S3 in the office that we can use to test this. That being said, I think this happens on any device based on what I see here.
Also, is the device using WiFi or Mobile Data? I don't think I've ever seen that asked, but I might be wrong. It may be that the latency on HSPA may suck and you can't immediately upload one file after another without a brief wait period or something, which wouldn't be present on an emulator unless you specifically set up the emulator to simulate mobile data.
I think I seem to be struggling with the same issue (on a Nexus 4, Android 4.2, Cordova 2.6.0). Multiple uploads to my server work as long as I disable any downloads in between, otherwise they fail some or all of the time. I managed to find a temporary work around by passing the 'Connection:close' header in my download requests.
like this:
fileTransfer.download( source, target, successCallback, errorCallback , false ,{ headers: { "Connection":"close" } } );
Ok, as promised, there's a demo project (using 2.8.0) for Android, which has been tested on the Samsung Galaxy S3, which exhibits this error, I've set the default upload URL to use http://posttestserver.com so that we can avoid concerns about the "quality" of the server, this is a demo server, which is used many times every day. (it's written in PHP FYI)
It will respond with the location of a post log, which will include a url for the uploaded photo
The app expects you to take a photo before uploading.
You are able to edit:
- Service/Host url
- Parameter/key name
- HTTP method (POST or PUT)
I've also tested this on a Nexus 7 tablet, and notice that we get the same error for EVERY upload attempt, so there are clearly device specific issues at play. (same code 3 error)
Demo project url: https://github.com/jasonm23/cordova-android-upload-test
Side note, just in case it wasn't clear, http://posttestserver.com/ has nothing to do with me or my clients.
Thanks for this Jason. Likely this won't get looked at until after 3.0 (in a couple of weeks). I'm sure it'll get picked up soon after though.
Just to provide some additional information since I just stumbled about this bug. I'm using an Samsung Galaxy Nexus with Stock 4.2.2 and Cordova 2.9. I had the exact same error as the original reporter (1st upload: success, 2nd: error, 3rd: success, 4th: error and so on).
I was successfully able to work around the problem by passing the `Connection: close` header with the upload. So until this issue can by solved correct I would recommend setting this header as a default.
I'm not an Cordova developer but I would suspect that there is some connection reuse issue either in cordova or in the underlying HTTP library. I would assume that the HTTP connection is reused for further request and when the exception is triggered this connection is closed to assure a clean state. This would explain why the issue only happens on each second request.
Hi Martin Thurau, I tried adding the `Connection: close` header, but the problem still persists (when testing on a Samsung Galaxy S3, every other fails, on Nexus7 Tablet, every upload fails.)
I can confirm the problem still exists in Cordova 2.9
08-22 14:42:54.619: D/FileTransfer(22007): fileKey: photo
08-22 14:42:54.619: D/FileTransfer(22007): fileName: 1377207773325.jpg
08-22 14:42:54.619: D/FileTransfer(22007): mimeType: image/jpeg
08-22 14:42:54.619: D/FileTransfer(22007): params: {}
08-22 14:42:54.619: D/FileTransfer(22007): trustEveryone: false
08-22 14:42:54.619: D/FileTransfer(22007): chunkedMode: true
08-22 14:42:54.619: D/FileTransfer(22007): headers: null
08-22 14:42:54.619: D/FileTransfer(22007): objectId: 2
08-22 14:42:54.619: D/FileTransfer(22007): httpMethod: POST
08-22 14:42:54.639: D/dalvikvm(22007): GC_EXPLICIT freed 31262K, 95% free 4093K/70964K, paused 3ms+11ms, total 33ms
08-22 14:42:54.639: D/FileTransfer(22007): Content Length: 211809
08-22 14:42:54.649: W/CursorWrapperInner(22007): Cursor finalized without prior close()
08-22 14:42:54.779: W/FileTransfer(22007): Error getting HTTP status code from connection.
08-22 14:42:54.779: W/FileTransfer(22007): java.io.EOFException
08-22 14:42:54.779: W/FileTransfer(22007): at com.squareup.okhttp.internal.Util.readAsciiLine(Util.java:314)
08-22 14:42:54.779: W/FileTransfer(22007): at com.squareup.okhttp.internal.http.RawHeaders.fromBytes(RawHeaders.java:301)
08-22 14:42:54.779: W/FileTransfer(22007): at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:130)
08-22 14:42:54.779: W/FileTransfer(22007): at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:630)
08-22 14:42:54.779: W/FileTransfer(22007): at com.squareup.okhttp.internal.http.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:385)
08-22 14:42:54.779: W/FileTransfer(22007): at com.squareup.okhttp.internal.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:334)
08-22 14:42:54.779: W/FileTransfer(22007): at com.squareup.okhttp.internal.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:534)
08-22 14:42:54.779: W/FileTransfer(22007): at org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:594)
08-22 14:42:54.779: W/FileTransfer(22007): at org.apache.cordova.FileTransfer.access$700(FileTransfer.java:69)
08-22 14:42:54.779: W/FileTransfer(22007): at org.apache.cordova.FileTransfer$1.run(FileTransfer.java:494)
08-22 14:42:54.779: W/FileTransfer(22007): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080)
08-22 14:42:54.779: W/FileTransfer(22007): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
08-22 14:42:54.779: W/FileTransfer(22007): at java.lang.Thread.run(Thread.java:856)
08-22 14:42:54.789: E/FileTransfer(22007):
08-22 14:42:54.789: E/FileTransfer(22007): java.net.SocketException: sendto failed: EPIPE (Broken pipe)
08-22 14:42:54.789: E/FileTransfer(22007): at libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
08-22 14:42:54.789: E/FileTransfer(22007): at libcore.io.IoBridge.sendto(IoBridge.java:475)
08-22 14:42:54.789: E/FileTransfer(22007): at java.net.PlainSocketImpl.write(PlainSocketImpl.java:507)
08-22 14:42:54.789: E/FileTransfer(22007): at java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
08-22 14:42:54.789: E/FileTransfer(22007): at java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:269)
08-22 14:42:54.789: E/FileTransfer(22007): at java.io.BufferedOutputStream.write(BufferedOutputStream.java:131)
08-22 14:42:54.789: E/FileTransfer(22007): at com.squareup.okhttp.internal.http.HttpTransport$FixedLengthOutputStream.write(HttpTransport.java:228)
08-22 14:42:54.789: E/FileTransfer(22007): at com.squareup.okhttp.internal.FaultRecoveringOutputStream.write(FaultRecoveringOutputStream.java:60)
08-22 14:42:54.789: E/FileTransfer(22007): at org.apache.cordova.FileTransfer$1.run(FileTransfer.java:425)
08-22 14:42:54.789: E/FileTransfer(22007): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080)
08-22 14:42:54.789: E/FileTransfer(22007): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
08-22 14:42:54.789: E/FileTransfer(22007): at java.lang.Thread.run(Thread.java:856)
08-22 14:42:54.789: E/FileTransfer(22007): Caused by: libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
08-22 14:42:54.789: E/FileTransfer(22007): at libcore.io.Posix.sendtoBytes(Native Method)
08-22 14:42:54.789: E/FileTransfer(22007): at libcore.io.Posix.sendto(Posix.java:151)
08-22 14:42:54.789: E/FileTransfer(22007): at libcore.io.BlockGuardOs.sendto(BlockGuardOs.java:177)
08-22 14:42:54.789: E/FileTransfer(22007): at libcore.io.IoBridge.sendto(IoBridge.java:473)
08-22 14:42:54.789: E/FileTransfer(22007): ... 10 more
08-22 14:42:54.789: E/FileTransfer(22007): Failed after uploading 65649 of 211809 bytes.
I can confirm it is still an issue in version 3.0.0.
It occurs for me intermittently, on a HTC phone, and any virtual devices.
I have tried the suggested fixes.
- Add System.setProperty("http.keepAlive", "false");
- Remove conn.setRequestProperty("Connection", "Keep-Alive"); from FileTransfer.java. It already does not exist.
I can also confirm that when the error occurs it is not hitting the server at all, even though it says Sent 15007 of 15007.
08-29 15:06:55.172: D/FileTransfer(531): upload content://media/external/images/media/14 to http://exampledomain.com?page=do_upload
08-29 15:06:55.172: D/FileTransfer(531): fileKey: image
08-29 15:06:55.172: D/FileTransfer(531): fileName: 14
08-29 15:06:55.172: D/FileTransfer(531): mimeType: image/jpeg
08-29 15:06:55.172: D/FileTransfer(531): params: {}
08-29 15:06:55.172: D/FileTransfer(531): trustEveryone: true
08-29 15:06:55.172: D/FileTransfer(531): chunkedMode: false
08-29 15:06:55.172: D/FileTransfer(531): headers: null
08-29 15:06:55.172: D/FileTransfer(531): objectId: 1
08-29 15:06:55.172: D/FileTransfer(531): httpMethod: POST
08-29 15:06:55.192: D/FileTransfer(531): Content Length: 15007
08-29 15:06:55.202: D/FileTransfer(531): Sent 15007 of 15007
08-29 15:06:55.202: W/PluginManager(531): THREAD WARNING: exec() call to FileTransfer.upload blocked the main thread for 54ms. Plugin should use CordovaInterface.getThreadPool().
08-29 15:06:55.212: W/FileTransfer(531): Error getting HTTP status code from connection.
08-29 15:06:55.212: W/FileTransfer(531): java.io.EOFException
08-29 15:06:55.212: W/FileTransfer(531): at com.squareup.okhttp.internal.Util.readAsciiLine(Util.java:314)
08-29 15:06:55.212: W/FileTransfer(531): at com.squareup.okhttp.internal.http.RawHeaders.fromBytes(RawHeaders.java:301)
08-29 15:06:55.212: W/FileTransfer(531): at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:130)
08-29 15:06:55.212: W/FileTransfer(531): at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:630)
08-29 15:06:55.212: W/FileTransfer(531): at com.squareup.okhttp.internal.http.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:385)
08-29 15:06:55.212: W/FileTransfer(531): at com.squareup.okhttp.internal.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:334)
08-29 15:06:55.212: W/FileTransfer(531): at com.squareup.okhttp.internal.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:534)
08-29 15:06:55.212: W/FileTransfer(531): at org.apache.cordova.filetransfer.FileTransfer$3.run(FileTransfer.java:444)
08-29 15:06:55.212: W/FileTransfer(531): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
08-29 15:06:55.212: W/FileTransfer(531): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
08-29 15:06:55.212: W/FileTransfer(531): at java.lang.Thread.run(Thread.java:856)
08-29 15:06:55.223: E/FileTransfer(531):
08-29 15:06:55.223: E/FileTransfer(531): java.io.EOFException
08-29 15:06:55.223: E/FileTransfer(531): at com.squareup.okhttp.internal.Util.readAsciiLine(Util.java:314)
08-29 15:06:55.223: E/FileTransfer(531): at com.squareup.okhttp.internal.http.RawHeaders.fromBytes(RawHeaders.java:301)
08-29 15:06:55.223: E/FileTransfer(531): at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:130)
08-29 15:06:55.223: E/FileTransfer(531): at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:630)
08-29 15:06:55.223: E/FileTransfer(531): at com.squareup.okhttp.internal.http.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:385)
08-29 15:06:55.223: E/FileTransfer(531): at com.squareup.okhttp.internal.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:334)
08-29 15:06:55.223: E/FileTransfer(531): at com.squareup.okhttp.internal.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:534)
08-29 15:06:55.223: E/FileTransfer(531): at org.apache.cordova.filetransfer.FileTransfer$3.run(FileTransfer.java:444)
08-29 15:06:55.223: E/FileTransfer(531): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
08-29 15:06:55.223: E/FileTransfer(531): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
08-29 15:06:55.223: E/FileTransfer(531): at java.lang.Thread.run(Thread.java:856)
08-29 15:06:55.223: E/FileTransfer(531): Failed after uploading 15007 of 15007 bytes.
*Update*
In addition to disabling chunking, I have added a header option which *so far* seems to have fixed the issue
var options = new FileUploadOptions(); options.headers = { Connection: "close" } options.chunkedMode = false; ft.upload(imgUrl, PATH, uploadSuccess, uploadFail, options);
Hello. Just want to know if someone is working on this.
Here there are three differents tries using a Galaxy S3 Android 4.1.1
1. FAILS
09-11 10:39:21.844: W/FileTransfer(4301): Error getting HTTP status code from connection.
09-11 10:39:21.844: W/FileTransfer(4301): java.io.EOFException
09-11 10:39:21.844: W/FileTransfer(4301): at libcore.io.Streams.readAsciiLine(Streams.java:203)
09-11 10:39:21.844: W/FileTransfer(4301): at libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
09-11 10:39:21.844: W/FileTransfer(4301): at libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
09-11 10:39:21.844: W/FileTransfer(4301): at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
09-11 10:39:21.844: W/FileTransfer(4301): at libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
09-11 10:39:21.844: W/FileTransfer(4301): at org.apache.cordova.FileTransfer$1.run(FileTransfer.java:484)
09-11 10:39:21.844: W/FileTransfer(4301): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
09-11 10:39:21.844: W/FileTransfer(4301): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
09-11 10:39:21.844: W/FileTransfer(4301): at java.lang.Thread.run(Thread.java:856)
09-11 10:39:21.884: E/FileTransfer(4301):
09-11 10:39:21.884: E/FileTransfer(4301): java.io.EOFException
09-11 10:39:21.884: E/FileTransfer(4301): at libcore.io.Streams.readAsciiLine(Streams.java:203)
09-11 10:39:21.884: E/FileTransfer(4301): at libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
09-11 10:39:21.884: E/FileTransfer(4301): at libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
09-11 10:39:21.884: E/FileTransfer(4301): at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
09-11 10:39:21.884: E/FileTransfer(4301): at libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
09-11 10:39:21.884: E/FileTransfer(4301): at org.apache.cordova.FileTransfer$1.run(FileTransfer.java:484)
09-11 10:39:21.884: E/FileTransfer(4301): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
09-11 10:39:21.884: E/FileTransfer(4301): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
09-11 10:39:21.884: E/FileTransfer(4301): at java.lang.Thread.run(Thread.java:856)
09-11 10:39:21.884: E/FileTransfer(4301): Failed after uploading 12137 of 12137 bytes.
2. SUCCESS
09-11 15:12:06.267: D/FileTransfer(15419): upload file:///storage/sdcard0/MYAPP_MEDIAS/1378926708422.jpg to http://myserver:8080/test/ajaxdispatch
09-11 15:12:06.267: D/FileTransfer(15419): fileKey: file
09-11 15:12:06.267: D/FileTransfer(15419): fileName: 1378926708422.jpg
09-11 15:12:06.267: D/FileTransfer(15419): mimeType: image/jpeg
09-11 15:12:06.277: D/FileTransfer(15419): params: {}
09-11 15:12:06.277: D/FileTransfer(15419): trustEveryone: true
09-11 15:12:06.277: D/FileTransfer(15419): chunkedMode: true
09-11 15:12:06.277: D/FileTransfer(15419): headers: null
09-11 15:12:06.277: D/FileTransfer(15419): objectId: 3
09-11 15:12:06.277: D/FileTransfer(15419): httpMethod: POST
09-11 15:12:06.327: D/FileTransfer(15419): Content Length: 2024908
09-11 15:12:06.457: D/FileTransfer(15419): Uploaded 115287 of 2024908 bytes
09-11 15:12:06.567: D/FileTransfer(15419): Uploaded 229975 of 2024908 bytes
09-11 15:12:06.648: D/FileTransfer(15419): Uploaded 344663 of 2024908 bytes
09-11 15:12:06.738: D/FileTransfer(15419): Uploaded 459351 of 2024908 bytes
09-11 15:12:06.878: D/FileTransfer(15419): Uploaded 574039 of 2024908 bytes
09-11 15:12:06.968: D/FileTransfer(15419): Uploaded 688727 of 2024908 bytes
09-11 15:12:07.078: D/FileTransfer(15419): Uploaded 803415 of 2024908 bytes
09-11 15:12:07.218: D/FileTransfer(15419): Uploaded 918103 of 2024908 bytes
09-11 15:12:07.378: D/FileTransfer(15419): Uploaded 1032791 of 2024908 bytes
09-11 15:12:07.508: D/FileTransfer(15419): Uploaded 1147479 of 2024908 bytes
09-11 15:12:07.629: D/FileTransfer(15419): Uploaded 1262167 of 2024908 bytes
09-11 15:12:07.739: D/FileTransfer(15419): Uploaded 1376855 of 2024908 bytes
09-11 15:12:07.869: D/FileTransfer(15419): Uploaded 1491543 of 2024908 bytes
09-11 15:12:08.029: D/FileTransfer(15419): Uploaded 1606231 of 2024908 bytes
09-11 15:12:08.249: D/FileTransfer(15419): Uploaded 1720919 of 2024908 bytes
09-11 15:12:08.399: D/FileTransfer(15419): Uploaded 1835607 of 2024908 bytes
09-11 15:12:08.479: D/FileTransfer(15419): Uploaded 1950295 of 2024908 bytes
09-11 15:12:08.550: D/FileTransfer(15419): Sent 2024908 of 2024908
09-11 15:12:08.800: D/FileTransfer(15419): response code: 200
09-11 15:12:08.810: D/FileTransfer(15419): response headers:
09-11 15:12:08.810: D/FileTransfer(15419): got response from server
3. FAILS
09-11 15:16:51.427: W/CursorWrapperInner(15904): Cursor finalized without prior close()
09-11 15:16:51.427: W/CursorWrapperInner(15904): Cursor finalized without prior close()
09-11 15:16:51.437: D/webcore(15904): CORE loadUrl: called
09-11 15:16:51.437: D/webkit(15904): Firewall not null
09-11 15:16:51.437: D/webkit(15904): euler: isUrlBlocked = false
09-11 15:16:51.517: D/WebKit(15904): ERROR:
09-11 15:16:51.517: D/WebKit(15904): WebKit does not yet implement getComputedStyle for 'border-radius'.
09-11 15:16:51.517: D/WebKit(15904): external/webkit/Source/WebCore/css/CSSComputedStyleDeclaration.cpp(935) : void WebCore::logUnimplementedPropertyID(int)
09-11 15:16:56.793: D/webview(15904): blockWebkitViewMessage= false
09-11 15:17:04.571: D/FileTransfer(15904): upload file:///storage/sdcard0/JMAP_MEDIAS/1378927011187.jpg to http://192.168.0.230:8080/test/ajaxdispatch
09-11 15:17:04.571: D/FileTransfer(15904): fileKey: file
09-11 15:17:04.571: D/FileTransfer(15904): fileName: 1378927011187.jpg
09-11 15:17:04.571: D/FileTransfer(15904): mimeType: image/jpeg
09-11 15:17:04.571: D/FileTransfer(15904): params:
09-11 15:17:04.571: D/FileTransfer(15904): trustEveryone: true
09-11 15:17:04.571: D/FileTransfer(15904): chunkedMode: true
09-11 15:17:04.581: D/FileTransfer(15904): headers: null
09-11 15:17:04.581: D/FileTransfer(15904): objectId: 2
09-11 15:17:04.581: D/FileTransfer(15904): httpMethod: POST
09-11 15:17:04.641: D/FileTransfer(15904): Content Length: 2213229
09-11 15:17:04.781: D/FileTransfer(15904): Uploaded 115287 of 2213229 bytes
09-11 15:17:04.902: W/FileTransfer(15904): Error getting HTTP status code from connection.
09-11 15:17:04.902: W/FileTransfer(15904): java.io.EOFException
09-11 15:17:04.902: W/FileTransfer(15904): at libcore.io.Streams.readAsciiLine(Streams.java:203)
09-11 15:17:04.902: W/FileTransfer(15904): at libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
09-11 15:17:04.902: W/FileTransfer(15904): at libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
09-11 15:17:04.902: W/FileTransfer(15904): at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
09-11 15:17:04.902: W/FileTransfer(15904): at libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
09-11 15:17:04.902: W/FileTransfer(15904): at org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:626)
09-11 15:17:04.902: W/FileTransfer(15904): at org.apache.cordova.FileTransfer.access$600(FileTransfer.java:67)
09-11 15:17:04.902: W/FileTransfer(15904): at org.apache.cordova.FileTransfer$1.run(FileTransfer.java:523)
09-11 15:17:04.902: W/FileTransfer(15904): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
09-11 15:17:04.902: W/FileTransfer(15904): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
09-11 15:17:04.902: W/FileTransfer(15904): at java.lang.Thread.run(Thread.java:856)
09-11 15:17:04.932: E/FileTransfer(15904):
09-11 15:17:04.932: E/FileTransfer(15904): java.net.SocketException: sendto failed: EPIPE (Broken pipe)
09-11 15:17:04.932: E/FileTransfer(15904): at libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
09-11 15:17:04.932: E/FileTransfer(15904): at libcore.io.IoBridge.sendto(IoBridge.java:475)
09-11 15:17:04.932: E/FileTransfer(15904): at java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
09-11 15:17:04.932: E/FileTransfer(15904): at java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
09-11 15:17:04.932: E/FileTransfer(15904): at java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
09-11 15:17:04.932: E/FileTransfer(15904): at libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
09-11 15:17:04.932: E/FileTransfer(15904): at org.apache.cordova.FileTransfer$1.run(FileTransfer.java:454)
09-11 15:17:04.932: E/FileTransfer(15904): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
09-11 15:17:04.932: E/FileTransfer(15904): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
09-11 15:17:04.932: E/FileTransfer(15904): at java.lang.Thread.run(Thread.java:856)
09-11 15:17:04.932: E/FileTransfer(15904): Caused by: libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
09-11 15:17:04.932: E/FileTransfer(15904): at libcore.io.Posix.sendtoBytes(Native Method)
09-11 15:17:04.932: E/FileTransfer(15904): at libcore.io.Posix.sendto(Posix.java:146)
09-11 15:17:04.932: E/FileTransfer(15904): at libcore.io.BlockGuardOs.sendto(BlockGuardOs.java:177)
09-11 15:17:04.932: E/FileTransfer(15904): at libcore.io.IoBridge.sendto(IoBridge.java:473)
09-11 15:17:04.932: E/FileTransfer(15904): ... 8 more
09-11 15:17:04.932: E/FileTransfer(15904): Failed after uploading 180823 of 2213229 bytes.
Looks like a newer version of OkHttp has a chance of fixing this.
Particularly this commit looks promising:
https://github.com/square/okhttp/commit/155a516b54ed60ec796cf5b9f2d8705012c5ceae
It's not included in a released version yet though.
Yes, this issue is still there when uploading multiple file. Is there any workaround? I tried keeping this in code too options.headers =
{ Connection: "close" }But all in vain.
There were some fixes to OkHttp that sound promising:
https://github.com/square/okhttp/commit/155a516b54ed60ec796cf5b9f2d8705012c5ceae
It's possible that if you update the version of OkHttp that the problem will be fixed.
You would do so by:
1. Check out cordova-android from https://git-wip-us.apache.org/repos/asf?p=cordova-android.git
2. Swap in a new version of OkHttp (under framework/src/com/squareup/okhttp)
3. Go into your projects/android directory
4. Run path/to/cordova-android/bin/update
If that doesn't work, then a work-around is to just retry a failed request.
I'm also hitting an error code 3 with no other info on Android, when iOS is still working. I have both chunked-mode false and Connection: 'close' header., and have the right permissions in my AndroidManifest.xml.
I have not tried Andrew's recommendation above as I'm not sure what exactly the "swapping in" process of step 2 would look like (this is my first Phonegap project).
I realize I'm not adding much new here, but this ticket has been open for a while (could very well be more than one issue), and I thought it worth noting that I'm hitting this with Cordova 3.1, Android 4.3 (since this conversation started with Cordova 2.2/2.3). Uploading audio to S3. iOS version works fine.
Please let me know if there are other (hopefully frontend) ways people have worked around this...
I have the same issue on my Android phone (4.2.2) with Phonegap 3.3.
12-24 11:51:44.160: E/FileTransfer(28597): at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:630)
12-24 11:51:44.160: E/FileTransfer(28597): at com.squareup.okhttp.internal.http.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:385)
12-24 11:51:44.160: E/FileTransfer(28597): at com.squareup.okhttp.internal.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:334)
12-24 11:51:44.160: E/FileTransfer(28597): at com.squareup.okhttp.internal.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:534)
12-24 11:51:44.160: E/FileTransfer(28597): at org.apache.cordova.filetransfer.FileTransfer$3.run(FileTransfer.java:444)
12-24 11:51:44.160: E/FileTransfer(28597): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080)
12-24 11:51:44.160: E/FileTransfer(28597): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
12-24 11:51:44.160: E/FileTransfer(28597): at java.lang.Thread.run(Thread.java:856)
Ok same problem here, is there perhaps another thread where this issue is discussed?
I'm using Cordova 3.3.1 on Android 4.2.2
Googling a bit I found this http://grandiz.com/phonegap-development/phonegap-file-transfer-error-code-3-solved/
I was able to upload multiple pictures by sending the header Connection: 'close' on the ft.upload.
Should Connection: close be set on every upload?
There is obviously some efficiency gained by maintaining open connections, but I think we can sacrifice that if we gain the ability to reliably upload multiple files.
I'm a little worried by David Kaneda's comment above, saying that Connection: close wasn't sufficient, but perhaps he was using it in such a way that the header didn't make it out to the actual request on the wire.
I'll add the header for all uploads in the dev version, and we can see if that improves the situation for those people still seeing this issue.
Cordova 3.4.0rc1 contains an updated version of OkHttp, which judging from it's changelog might address this issue.
If anyone would like to try it out:
npm install -g cordova@3.4.0-rc.1 cordova platform update android
This looks to be fixed by updating the OkHttp version within Cordova 3.4.0!
I'm facing a similar issue. The image upload fails in Windows Phone 8 (Nokia Lumia 720).
I'm using the latest stable version of the plugin r0.4.5 from below.
https://github.com/apache/cordova-plugin-file-transfer/blob/master/doc/index.md
The example mentioned as part of the plugin document from the above link is not working in Windows Phone 8.
The issue is with sending "params" object as part of the request "options". The upload works when "params" object is removed from the request.
There is a work around for this as we can send the required params as part of the server URL itself.
Example: https://someserver?param1="param1"¶m2="param2"
Sending params like above works. But of course your server side code should be able to extract it if required.
But there are many servers which discard any extra param being sent to it as part of the URl and would not consider it.
Anybody facing a similar issue and have found any alternate solution to this?
I've moved your comment to a new issue (CB-7326). It's almost certainly a different issue on WP8; this was an Android native-side problem.
Hey guys, just wanted to point out that this is once again an issue on Cordova 3.6
Added the connection close headers, and false to the upload method parameters as well as chunked mode = false.
Now it works again
I have passed trustAllHosts option true to file transfer plugin. All the alternate upload fails issue didn't occur again.
Can you please provide some example code for this issue?