Closed GoogleCodeExporter closed 8 years ago
I'm also receiving this error. I'm using Android 2.2 with KSOAP2 2.4. I'm
calling the following wed service if it helps.
private static final String
SOAP_ACTION="http://opendap.co-ops.nos.noaa.gov/axis/services/highlowtidepred/ws
dl";
private static final String METHOD_NAME = "getHLPredAndMetadata";
private static final String NAMESPACE = "http://opendap.co-ops.nos.noaa.gov/axis/webservices/highlowtidepred/wsdl";
private static final String URL = "http://opendap.co-ops.nos.noaa.gov/axis/webservices/highlowtidepred/wsdl";
Original comment by dale.hol...@gmail.com
on 30 Oct 2010 at 5:44
For now you can wrap a try catch around it and retry if you get this response
or swallow it. If you can fix it that would be great too. I can take a patch or
a pull request on github.
Original comment by mosa...@gmail.com
on 2 Nov 2010 at 3:47
For now it looks like this problem is only on emulator, because on real phone I
don't get any error even at small speeds.
Original comment by gapipro@gmail.com
on 2 Nov 2010 at 3:59
Ok... I know what you mean. There are some problems I read about in the google
code android issue list. If you dont mind I will close this issue then..
Original comment by mosa...@gmail.com
on 2 Nov 2010 at 4:01
[deleted comment]
[deleted comment]
I will close this issue since neither the submitter nor myself can reproduce it
on an actual phone.
Original comment by mosa...@gmail.com
on 8 Nov 2010 at 10:52
[deleted comment]
I'm able to recreate this on a phone. Works on the emulator, and if the phone
is in Wifi Mode. I get the problem on a Samsung Fascinate Galaxy S on the
verizon network. Android 2.1
Original comment by ealy.nat...@gmail.com
on 2 Dec 2010 at 6:34
Ok. I will reopen. Could you debug and fix maybe?
Original comment by mosa...@gmail.com
on 2 Dec 2010 at 6:45
Original comment by mosa...@gmail.com
on 2 Dec 2010 at 6:45
I've tried debugging it on the phone, but I don't get the error while
debugging. Only when it runs at full speed and in 3G mode. Works fine on Droid,
Droid2, and Droid X, and others.
Original comment by ealy.nat...@gmail.com
on 7 Dec 2010 at 5:02
Tried KSOAP 2.5.2. Didn't fix anything.
Original comment by ealy.nat...@gmail.com
on 7 Dec 2010 at 5:05
You will have to debug this in the ksoap project code base then. I am currently
using an automatic retry in my implementation but I have not checked for a long
time if I am still getting this problem. You could try to figure out the
problem in ksoap or implement a retry in your codebase.
Ideally if you can create a fix for it in ksoap if it is even the culprit
(could be something lower in the stack too) I will defintely pull it in.
Original comment by mosa...@gmail.com
on 7 Dec 2010 at 5:15
I also have encountered this.
I'm using ksoap 2.5.2 on Android 2.2 (Nexus One) and Android 1.6 (Magic 32A).
I've noticed the followings:
1) it happens only in HTTPS
2) the first call works great, the second will fail.
3) the third call will work, the fourth will fail, and so on (fifth OK, sixth
fail)
I've "worked-around" (VERY ugly, I agree, and I will never will do it again, I
promise. Please don't yell), by wrapping "Transport.call" function with
try-catch and re-calling the function. This hides the problem very well :)
I'll be happy to help in anyway
Original comment by menn...@gmail.com
on 15 Dec 2010 at 4:07
[deleted comment]
Try to set system property: System.setProperty("http.keepAlive", "false"). It
helped me to solve similar problem. Helpful info on
http://stackoverflow.com/questions/3352424/httpurlconnection-openconnection-fail
s-second-time
Original comment by izhov...@gmail.com
on 15 Dec 2010 at 4:18
It fixed it :)
Any idea why it happens?
Original comment by menn...@gmail.com
on 15 Dec 2010 at 4:23
It is because of a problem in android implementation of HTTPUrlConnection, used
in kSOAP2 transport. It does not properly support keep alive connections. See
Issue 7786 here: http://code.google.com/p/android/issues/detail?id=7786
Original comment by izhov...@gmail.com
on 15 Dec 2010 at 4:51
Just fyi you do not have to do that yourself. I have implemented and included a
class that does exactly that in Ksoap when I added the HttpsTransport .. it
called... surprise. KeepAliveHttpsTransportSE. That should do the trick...
https://github.com/mosabua/ksoap2-android/blob/master/ksoap2-j2se/src/main/java/
org/ksoap2/transport/KeepAliveHttpsTransportSE.java
Original comment by mosa...@gmail.com
on 15 Dec 2010 at 4:57
Considering that the bug is basically in Android itself and we have a
workaround - can I close this issue? Maybe after adding something to the wiki
(like a FAQ item?).
Original comment by mosa...@gmail.com
on 15 Dec 2010 at 4:58
Is there an option to move to a different http client? Like HttpGet?
Original comment by menn...@gmail.com
on 15 Dec 2010 at 5:26
Well... you could implement another transport that uses HttpGet .. but I would
rather not change the existing ones. There is just too much code out there
using it and who knows what the side effects would be. But getting another
transport should be just fine. Feel free to give it a shot in your own github
clone of the project. If you get it to work I will pull it in..
Original comment by mosa...@gmail.com
on 15 Dec 2010 at 5:28
Closing since a workaround/fix exists and the underlying problem is in Android
itself.
Original comment by mosa...@gmail.com
on 15 Feb 2011 at 6:41
I had exactly the same issue like described by #15.
But only with Android 2.2. The Issue seems to be fixed in Android 2.3 itself.
In any case, your comment #20 is the solution to everything ;)
Vielen Dank!
Original comment by schmid...@gmail.com
on 28 Apr 2011 at 9:22
I am able to consistently reproduce this in my code, running with Android 2.2
emulator, ksoap2-android-2.5.4, using HttpTransportSE.call() (haven't tried
HttpsTransportSE).
Original comment by cgtyo...@gmail.com
on 19 May 2011 at 7:06
I also can reproduce this Exception through I use 'HttpsTransportSE' ,
running with Android2.1 emulator, ksoap2-2.5.4
So, I think the problem isn't end!
Original comment by Samuel.C...@gmail.com
on 23 May 2011 at 2:35
I am now also seeing this in HttpsTransportSE(), debugging on actual hardware -
Android 2.2.1 (Droid X). Can this issue be reopened?
Original comment by cgtyo...@gmail.com
on 24 May 2011 at 2:40
Have you tried the KeepAliveHttsTransport... it is the workaround that should
fix the problem.
Original comment by mosa...@gmail.com
on 24 May 2011 at 3:39
[deleted comment]
retry when timeout ,it's OK!
try {
Thread.sleep(300);
contactPhone_ht.call(null, contactPhone_envelope);
} catch (SocketTimeoutException e1) {
// TODO Auto-generated catch block
try {
contactPhone_ht.call(null, contactPhone_envelope);
} catch (SocketTimeoutException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
Original comment by QQ275683...@gmail.com
on 22 Jun 2011 at 7:55
[deleted comment]
I am getting this issue when using the HttpTransportSE class (i.e. not secure)
on both emulator and an android device.
When I try and use the KeepAliveHttsTransport I am treated to a null pointer
exception - I assume this is because by service isn't hosted securely.
Can anyone point in the right direction of solving this issue using standard
HTTP?
The Service is fully function from a browser.
Thanks
Original comment by tyretrad...@gmail.com
on 3 Aug 2011 at 8:35
You could implement a KeepAliveHttpTransport using the same approach used for
https, but it should just. Maybe provide more details in a separate issue or on
the mailing list.
Original comment by mosa...@gmail.com
on 5 Aug 2011 at 6:14
Hello. I have gotten the XMLPullParser exception on both emulator and my Droid
2. Is there any way to fix this? I am trying to a call a .NET WCF web service
and I keep getting this error. Is there a patch or update that anyone knows
about for this or if someone could point me in the right direction if they are
willing too. My email is mk352@njit.edu if anyone would like to help. Thanks
Original comment by mk...@njit.edu
on 9 Sep 2011 at 3:22
Ensure that you are getting a response back looking at the response dump with
debugging enabled. If not just retry automatically.
Original comment by mosa...@gmail.com
on 9 Sep 2011 at 4:22
Hi All
I had the same problem as menn...@gmail.com
I've noticed the followings:
1) it happens only in HTTPS
2) the first call works great, the second will fail.
3) the third call will work, the fourth will fail, and so on (fifth OK, sixth
fail)
The solution for me was to create a custom "CustomKeepAliveHttpsTransportSE"
and add the latest "KeepAliveHttpsTransportSE.java" code in there:
package santam.app.yourfriendcash.util;
import java.io.IOException;
import org.ksoap2.transport.HttpsServiceConnectionSE;
import org.ksoap2.transport.HttpsTransportSE;
import org.ksoap2.transport.ServiceConnection;
public class CustomKeepAliveHttpsTransportSE extends HttpsTransportSE {
private HttpsServiceConnectionSE conn = null;
private final String host;
private final int port;
private final String file;
private final int timeout;
public CustomKeepAliveHttpsTransportSE (String host, int port, String file, int timeout) {
super(host, port, file, timeout);
this.host = host;
this.port = port;
this.file = file;
this.timeout = timeout;
}
/**
* Get a service connection. Returns an implementation of {@link org.ksoap2.transport.ServiceConnectionSE} that
* ignores "Connection: close" request property setting and has "Connection: keep-alive" always set and is uses
* a https connection.
* @see org.ksoap2.transport.HttpTransportSE#getServiceConnection()
*/
//@Override
public ServiceConnection getServiceConnection() throws IOException
{
conn = new HttpsServiceConnectionSE(host, port, file, timeout)
{
//@Override
public void setRequestProperty(String key, String value) {
// We want to ignore any setting of "Connection: close" because
// it is buggy with Android SSL.
if ("Connection".equalsIgnoreCase(key) && "close".equalsIgnoreCase(value)) {
return;
} else {
super.setRequestProperty(key, value);
}
}
};
conn.setRequestProperty("Connection", "keep-alive");
return conn;
}
}
Then I did this in my "HttpTransportSSLManager" where I call my TransportSE
class:
public SoapSerializationEnvelope call(String soapAction,
SoapSerializationEnvelope envelope, String username, String password){
try {
List<HeaderProperty> headers = new ArrayList<HeaderProperty>();
String authentication = android.util.Base64.encodeToString((username+":"+password).getBytes(), android.util.Base64.NO_WRAP);
headers.add(new HeaderProperty("Authorization", "Basic " + authentication));
CustomKeepAliveHttpsTransportSE httpsTransportSE = new CustomKeepAliveHttpsTransportSE(ActivityManager.HOST, ActivityManager.PORT, ActivityManager.FILE, ActivityManager.TIMEOUT);
//httpsTransportSE.setXmlVersionTag("<?xml version=\"1.0\" encoding= \"UTF-8\"?>");
httpsTransportSE.debug = true;
httpsTransportSE.call(soapAction, envelope, headers);
//String requestDump = httpsTransportSE.requestDump;
//String responseDump = httpsTransportSE.responseDump;
return envelope;
} catch (IOException e) {
throw new RuntimeException(e);
}
catch (XmlPullParserException e) {
throw new RuntimeException(e);
}
}
After this I did not get the "XmlPullParserException" anymore hope this helps
someone :)
Original comment by gideon....@gmail.com
on 18 Jan 2013 at 12:25
Attachments:
The problem actually is that you must use "KeepAliveHttpsTransportSE" and not
the "HttpsTransportSE" class. Then the "KeepAliveHttpsTransportSE" is not the
latest code so you need to get the latest "KeepAliveHttpsTransportSE.java" file
from the ksoap2 source. It must say in the class in comments:
// We want to ignore any setting of "Connection: close" because
// it is buggy with Android SSL.
Then you know you have the right class. Then just rename
"KeepAliveHttpsTransportSE.java" to "CustomKeepAliveHttpsTransportSE" and
import everything. Then use
CustomKeepAliveHttpsTransportSE httpsTransportSE = new
CustomKeepAliveHttpsTransportSE(HOST, PORT, FILE, ActivityManager.TIMEOUT);
in place of
CustomKeepAliveHttpsTransportSE httpsTransportSE = new
CustomKeepAliveHttpsTransportSE(HOST, PORT, FILE, ActivityManager.TIMEOUT);
Hope this makes sense.
Original comment by gideon....@gmail.com
on 18 Jan 2013 at 12:31
Original issue reported on code.google.com by
gapipro@gmail.com
on 24 Oct 2010 at 4:24