Thanks, Oleg. This does help. I think the only thing jclouds cares about in the 4.1 list is the threadsafe HttpParams, which is also not really a big deal.
http core performance is not a limiting factor for jclouds. Good work! -Adrian On Wed, Jun 24, 2009 at 3:33 PM, Oleg Kalnichevski <[email protected]> wrote: > On Wed, Jun 24, 2009 at 11:21:33AM +0200, Adrian Cole wrote: > > Thanks for the work on this, Oleg. I'm upgrading today. Any news on > what > > to expect for 4.1? > > > > Thanks, > > -Adrian > > jclouds > > > > > > Hi Adrian, > > The most important change targeted for 4.1 release is improved > compatibility with JREs with naive (broken) implementation of SelectionKey > such as IBM's. I also would like to invest some time in performance > optimization of some classes, but this is optional as so far there have been > no complaints about HttpCore performance (barring the issue with IBM JRE > 6.0). The detailed list of JIRAs targeted for 4.1 can be found here: > > https://issues.apache.org/jira/browse/HTTPCORE/fixforversion/12313548 > > Hope this helps > > Oleg > > > > On Mon, Jun 22, 2009 at 8:43 PM, Oleg Kalnichevski <[email protected]> > wrote: > > > > > The Apache HttpComponents project is pleased to announce the release of > > > HttpComponents HttpCore 4.0.1. > > > > > > This is a patch release addressing a number of issues discovered since > the > > > 4.0 release. Users of NIO module are advised to upgrade. > > > > > > 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: blocking I/O model based > on the > > > classic Java I/O and 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] > >
