Performance problems with HTTPS

[chudak]

Yes I'm using M2.

FYI, I'm pretty sure that it's not a problem with the spring code base but with the commons httpcomponent library.

When I switched out the default client request factory the problem went away. However, I did find a problem with the SimpleHttpClientRequestFactory. When I used that one it seemed like every other request would fail in the emulator. But when I ran unit tests in a JVM it worked fine.

I ended up using the deprecated CommonsClientHttpRequestFactory and the problem went away.

FWIW, I think the problem is with the default host name verification algorithm in the http components library. When I did some profiling of my code in the emulator that appeared to be the bottleneck. For whatever reason, it works fine in the JVM but when you run it in the dalvik vm on an emulator (or on a device) it's super slow.

I didn't try switching out the hostname verifier but that was another option I was going to try.

You may want to rethink removing support for the http client, at least in the near future.

[Roy Clarkson]

Ok, thanks for the additional information. Just to summarize, the SimpleClientHttpRequestFactory uses the java.net package. I've read, and your experience seems to be consistent, that some people have had issues with the Android implementation. I haven't personally seen this, but that is one reason we chose to default to the CommonsClientHttpRequestFactory in M1. The other being that SpringFramework already had a working implementation of the commons client.

As you know, the commons 3.x http client is not native to Android. SpringFramework didn't have a HttpComponents implementation in Spring Web at the time, so the HttpComponentsClientHttpRequestFactory in SpringAndroid is the first implementation we've had. Since the HttpComponents 4.0 client is also native to Android we decided to default to it in the M2 release and deprecate the commons 3.x client, to discourage pulling in the commons client jar. In fact, I've already removed it in the latest build snapshot.

Being native doesn't necessary mean it's better. The Android HttpComponents implementation is quite old, as this stackoverflow thread indicates. HttpComponents 4.1 is now available, so we'll probably want to have an implementation available in Spring Android, which would also require an external dependency.

http://stackoverflow.com/questions/5...ion-on-android

But you bring up a good point about being able to compare functionality of each of these. So in that light, it's probably worth leaving the commons client as an option, but not defaulting to it. Then if you elect, you can pull in the dependency and use it. Needless to say, your and the community's feedback and experiences are valuable in driving these decisions.