[
https://issues.apache.org/jira/browse/CXF-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009189#comment-13009189
]
Oleg Kalnichevski commented on CXF-291:
---------------------------------------
@Daniel
For what it is worth to you.
You could base your client side HTTP code on the asynchronous version of
HttpClient [1] which would relieve the tedium of having to deal with the
non-blocking SSL (which is enormously painful), persistent connection
management, and similar low level stuff and help cut down on the amount of HTTP
protocol specific code quite dramatically. HttpAsyncClient is also based on
HttpCore NIO so migration _should_ be fairly straightforward.
As far as performance is concerned, it is perfectly expectable for a NIO based
transport to be ~25% slower in terms of raw throughput than a similar one based
on the classic (blocking) I/O model. Thread context switching in modern JREs
tends to be faster than selector based channel multiplexing.
Oleg
[1] http://hc.apache.org/httpcomponents-asyncclient-dev/index.html
> Support Commons HTTP Client for HTTP conduit
> --------------------------------------------
>
> Key: CXF-291
> URL: https://issues.apache.org/jira/browse/CXF-291
> Project: CXF
> Issue Type: New Feature
> Components: Transports
> Affects Versions: 2.0
> Reporter: Dan Diephouse
> Labels: gsoc2011
>
> I think commons http client is a must in terms of HTTP support as it supports
> a lot of different authentication modes that I don't know that we currently
> support. It shouldn't be that hard to integrate either. XFire users tend to
> depend pretty heavily on it. The XFire code can be found here:
> http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-core/src/main/org/codehaus/xfire/transport/http/CommonsHttpMessageSender.java
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
