Sounds great, and will do... Thanks, Dan
On Sat, Aug 20, 2011 at 6:05 PM, Oleg Kalnichevski <[email protected]> wrote: > On Sat, 2011-08-20 at 17:08 -0400, Dan Checkoway wrote: > > Cool, thanks Oleg. If you happen to have any online doc ready, can you > > point me in the right direction on that? > > > > I've got a bunch of code that's heavily dependent on > > ThreadSafeClientConnManager and would like to migrate to the "new way" > when > > it's ready. > > > > Thanks, > > Dan > > > > Dan, > > There is no need for you to migrate off ThreadSafeClientConnManager > until Httpclient 4.2 goes GA which is unlikely to happen before the end > of the year. Besides, the new pooling connection manager should be > pretty much a drop in replacement for ThreadSafeClientConnManager > requiring virtually no changes in application code. You might want to > take a look at the first ALPHA once it is ready and see how it fares. > > Oleg > > > On Sat, Aug 20, 2011 at 11:47 AM, Oleg Kalnichevski <[email protected] > >wrote: > > > > > On Sat, 2011-08-20 at 00:40 -0400, Dan Checkoway wrote: > > > > 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 > > > > > > > > > > The connection pool components are based on the > > > ThreadSafeClientConnManager code but have a slightly different API and > a > > > much smaller API footprint (all internal data structures of the > > > connection pool are now package private whereas they used to be > > > protected and it was almost impossible to change them without breaking > > > API compatibility). A new connection manager based on the new > connection > > > pool components from HttpCore will replace the > > > ThreadSafeClientConnManager in release 4.2. > > > > > > Oleg > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
