Oleg, I'm curious how the new stuff compares to ThreadSafeClientConnManager. Is there a new or different preferred methodology as of 4.2?
Thanks, Dan On Fri, Aug 19, 2011 at 11:25 AM, Oleg Kalnichevski <[email protected]>wrote: > The Apache HttpComponents project is pleased to announce the release of > HttpComponents HttpCore 4.2-alpha1. The most notable feature included in > this release is support for connection pools of blocking and > non-blocking HTTP connections. Connection pool components are based on > mature code migrated from HttpClient and HttpAsyncClient modules but > have a slightly different API that makes a better use of Java standard > concurrent primitives. > > Support for connection pools in HttpCore is expected to make development > of client and proxy HTTPservices easier and less error prone. > > Please note that new features included in this release are still > considered experimental and their API may change in the future ALPHA > releases. This release also marks the end of support for Java 1.3. As of > this release HttpCore requires Java 1.5 for all its components. Several > classes and methods deprecated between versions 4.0-beta1 and 4.0 GA > (more than two years ago) have been removed in this release. > > Download - > <http://hc.apache.org/downloads.cgi> > Release notes - > <http://www.apache.org/dist/httpcomponents/httpcore/RELEASE_NOTES.txt> > HttpComponents site - > <http://hc.apache.org/> > > About HttpComponents Core - > HttpCore is a set of low level HTTP transport components that can be > used to build custom client and server side HTTP services with a minimal > footprint. HttpCore supports two I/O models: a blocking I/O model based > on the classic Java I/O and a non-blocking, event driven I/O model based > on Java NIO. The blocking I/O model may be more appropriate for data > intensive, low latency scenarios, whereas the non-blocking model may be > more appropriate for high latency scenarios where raw data throughput is > less important than the ability to handle thousands of simultaneous HTTP > connections in a resource efficient manner. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
