You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Roland Weber <ht...@dubioso.net> on 2007/02/10 14:20:30 UTC
[HttpConn][HttpClient] status update
Hi folks,
I've reached a milestone with ClientRequestDirector. The replacement
for HttpMethodDirector is now able to establish secure connections
through a proxy. Along with that goes a first draft of HttpClient
that uses the CRD. If you should look at the API at this stage, please
remember that I'm _really_ still working on HTTPCLIENT-627 [1] and
need the CRD as a sanity check of the connection management API.
The rest of this mail is implementation details and an outlook.
I did not "port" HttpMethodDirector to the new API, as I found the
approach much too difficult. HMD is based on the HttpMethod concept
and full of authentication related code, which is out of scope for
the current problem. Instead I had HMD open in one editor window
and implemented the CRD in another one, using a top-down approach
to provide similar functionality. Wherever I left out functionality
found in HMD, I put in a comment. Likewise when I felt there is
an open question. The CRD code now looks as if more questions
are posed than answered. It's a scrag, but I still feel that it
is on the right track and that the missing functionality can be
fitted nicely.
To implement the route-building logic, I have added new classes that
match my "HTTP route" idea. HttpRoute is meant as a replacement for
HostConfiguration, which I would like to keep in a different role
after HTTPCLIENT-618 [2]. ManagedClientConn and ClientConnManager
are updated to use HttpRoute rather than HostConfiguration. TSCCM
still uses HostConfig internally, as I don't want to start cleaning
it up until there are testcases to ease Oleg's mind.
There is one tiny little hole in the client API... connections can
not yet be released. The examples send an OPTIONS request, which
will generate a response without entity. In that case, the CRD
releases the connection immediately.
Connection release will be the next milestone. I'm thinking about
an approach that relies on closing the input stream or entity rather
than a releaseConnection method, as suggested in [4]. It will involve
AutoCloseInputStream and check for connection re-use and some kind
of extended interface (don't know which one yet) and I don't know
what else. If possible, I will address HTTPCLIENT-589 [3] along the
way, plus the questions I raised some weeks ago in [5]. After that,
it's time for testcases and review.
cheers,
Roland
[1] https://issues.apache.org/jira/browse/HTTPCLIENT-627
[2] https://issues.apache.org/jira/browse/HTTPCLIENT-618
[3] https://issues.apache.org/jira/browse/HTTPCLIENT-589
[4]
http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200508.mbox/%3c304447CF-0A71-49C2-871D-5476E9F75226@symphonious.net%3e
[5]
http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200701.mbox/%3c45B333F3.3010706@dubioso.net%3e
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Tom Lipkis <ta...@pss.com>.
> Findbugs is pretty good at finding potentially unclosed streams, and a
> lot more besides ...
Findbugs is useful, but it can only find unclosed streams where it can
show that a stream is opened and goes out of scope with no close()
call. In many situations, static analysis isn't enough.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by sebb <se...@gmail.com>.
On 12/02/07, Tom Lipkis <ta...@pss.com> wrote:
> > We should modify that action, switching the stream
> > into an EOF mode where the underlying connection is no longer
> > blocked, but no IOExceptions are triggered either. I'll open
> > a JIRA issue for that.
>
> Thanks!
>
> > Regarding the tolerance debate, maybe we can add a "zero tolerance"
> > mode to the connection managers in HttpConn 4. One that shuts down
> > the JVM if a connection leak is detected. I'll keep it in mind.
>
> If you do this, please allow the application to decide what happens if
> the condition is detected. In testing, I might want to exit, but in
> production, exiting the JVM is a bit extreme.
>
> One tool I use to help locate unclosed streams is in
> http://lockss.cvs.sourceforge.net/lockss/lockss-daemon/src/org/lockss/util/MonitoringInputStream.java?revision=1.4&view=markup
> It records a stack trace when the stream is opened, which it logs iff
> the stream is GCed without having been closed.
>
Findbugs is pretty good at finding potentially unclosed streams, and a
lot more besides ...
S///
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Ortwin Glück <od...@odi.ch>.
Roland Weber wrote:
> Hi Tom,
>
>>> Regarding the tolerance debate, maybe we can add a "zero tolerance"
>>> mode to the connection managers in HttpConn 4. One that shuts down
>>> the JVM if a connection leak is detected. I'll keep it in mind.
>> If you do this, please allow the application to decide what happens if
>> the condition is detected. In testing, I might want to exit, but in
>> production, exiting the JVM is a bit extreme.
>
> OK. Auto-shutdown-mode, log-error-mode,...
J2EE servers like JBoss issue WARN log when they detect connection
leaks. And the detection can be disabled. They do that primarily to ease
debugging of Resource Adapters.
Odi
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Roland Weber <ht...@dubioso.net>.
Hi Tom,
>> Regarding the tolerance debate, maybe we can add a "zero tolerance"
>> mode to the connection managers in HttpConn 4. One that shuts down
>> the JVM if a connection leak is detected. I'll keep it in mind.
>
> If you do this, please allow the application to decide what happens if
> the condition is detected. In testing, I might want to exit, but in
> production, exiting the JVM is a bit extreme.
OK. Auto-shutdown-mode, log-error-mode,...
> One tool I use to help locate unclosed streams is in
> http://lockss.cvs.sourceforge.net/lockss/lockss-daemon/src/org/lockss/util/MonitoringInputStream.java?revision=1.4&view=markup
> It records a stack trace when the stream is opened, which it logs iff
> the stream is GCed without having been closed.
That sounds like an interesting approach. Maybe we can put that
as a hint in some user documentation.
Thanks,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Tom Lipkis <ta...@pss.com>.
> We should modify that action, switching the stream
> into an EOF mode where the underlying connection is no longer
> blocked, but no IOExceptions are triggered either. I'll open
> a JIRA issue for that.
Thanks!
> Regarding the tolerance debate, maybe we can add a "zero tolerance"
> mode to the connection managers in HttpConn 4. One that shuts down
> the JVM if a connection leak is detected. I'll keep it in mind.
If you do this, please allow the application to decide what happens if
the condition is detected. In testing, I might want to exit, but in
production, exiting the JVM is a bit extreme.
One tool I use to help locate unclosed streams is in
http://lockss.cvs.sourceforge.net/lockss/lockss-daemon/src/org/lockss/util/MonitoringInputStream.java?revision=1.4&view=markup
It records a stack trace when the stream is opened, which it logs iff
the stream is GCed without having been closed.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Roland Weber <ht...@dubioso.net>.
Hi Tom,
> I believe auto-close is a mistake (as is keeping it a secret :-). The
> code using the stream isn't notified when it's closed, which leads to
> unexpected IOExecptions.
I've thought it over and believe this is something that should be
addressed in 3.1. The auto-close code does exactly what your
workaraound does, too: it looks for an EOF and then triggers
an action. We should modify that action, switching the stream
into an EOF mode where the underlying connection is no longer
blocked, but no IOExceptions are triggered either. I'll open
a JIRA issue for that.
Auto-close has been a part of HttpClient for some years, so we
will not be dropping it from the 3.1 code. It's a performance
optimization and not meant to replace releaseConnection().
Regarding the tolerance debate, maybe we can add a "zero tolerance"
mode to the connection managers in HttpConn 4. One that shuts down
the JVM if a connection leak is detected. I'll keep it in mind.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Julius Davies <ju...@gmail.com>.
ps. One of my systems completely stopped working after being ignored
for a couple of months recently. When I finally got the thread
dump.... I'd forgotten to call releaseConnection()!
I've been following this mailing list for 2 years now! You'd think
I'd know better.
That's why I'm such a big fan of ditching releaseConnection() in
favour in InputStream.close(). I write code that opens and closes a
stream at least once a day. I write code that uses HttpClient maybe
once every 6 months.
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Tom Lipkis <ta...@pss.com>.
Julius,
> java.io.FileInputStream ... finalize()
IMHO, this was also a mistake. The finalize() method allows programs
that don't close streams to (appear to) work under light load, because
the GC runs often enough to close some streams before running out of
file descriptors. Under heavy load, that program will encounter
transient file opening failures. Without the finalize(), this would
be caught during testing, because a program that doesn't close its
streams will quickly run out of FDs. The finalize() makes it more
likely that this class of bugs will go undetected in development and
cause problems in the field. This is the "should frameworks
compensate for programmer errors" debate (which I'm happy to go on
with, but if so we should probably move it off-list).
auto-close also falls into this category, but additionally has a more
practical problem: it changes the semantics of the stream in a way
that causes it to not interoperate properly with, e.g,
BufferedInputStream. If the implementation of auto-close (actually,
auto-release) were changed to make it transparent, I'd have no problem
with it (except philosophically). Seems easier to make it optional,
though.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Julius Davies <ju...@gmail.com>.
Hi, Tom,
I support the "auto-close". But I still think all programmers should
still close their streams, anyway, even if the stream supports
"auto-close". This is why we don't tell anyone!
If a person doesn't finish reading all the data, then the auto-close
won't happen. But good programmers still close their stream in the
finally block. So it doesn't matter.
If the person is relatively new to java / or incompetent, the stream
gets garbage-collected. This person wasn't going to call
releaseConnection() anyway! As long as the AutoCloseInputStream
includes a finalize() method that closes itself for this worst case -
partial data read with no close() - we're okay:
protected void finalize() throws IOException {
close();
}
I know "finalize()" is to be avoided in 99.99999% of situations. This
is the one exception. Take a look to java.io.FileInputStream's source
code. It does the same. Implementing finalize() introduces a big
performance hit for garbage collection, but how many streams a second
are we going to be garbage collecting, anyway?
I think ditching "releaseConnection()" in favour of
InputStream.close() is very important. Automatically releasing when
EOF is read is more in spirit with a garbage-collecting language like
Java. It's a safety net for those days when we forget which bag in
the fridge is holding the real coffee, and accidentally grab the bag
holding the decaf.
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Tom Lipkis <ta...@pss.com>.
Roland,
> The purpose of the auto-close is to free the underlying connection for
> immediate re-use.
I understand. But that can't be counted on to happen (might not
finishing reading data), so any robust application has to call
releaseConnection() anyway (e.g., in a finally). Given that, I think
it's better for the library to enforce doing it right, rather than
smooth over such omissions, which can make buggy code look like it's
working. (But I've drifted a bit. I'm not really trying to settle
the "should frameworks compensate for programmer errors" debate. ;-)
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Roland Weber <ht...@dubioso.net>.
Hi Tom,
> I appreciate that some find the auto-close behavior useful, but I think
> it should be optional (and documented).
The purpose of the auto-close is to free the underlying connection for
immediate re-use. I think of it more as an auto-detach-from-connection
than an auto-close. Thanks for bringing the IOException problem to my
attention. I'll try to take that into account for 4.0.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Tom Lipkis <ta...@pss.com>.
> > By "AutoClose", I guess you mean that it will close itself if the EOF
> > is read? That makes sense.
>
> Yes. AFAIK that already happens in HttpClient 3.x. We just don't
> tell anybody, so keep it to yourself... ;-)
I believe auto-close is a mistake (as is keeping it a secret :-). The
code using the stream isn't notified when it's closed, which leads to
unexpected IOExecptions.
E.g., I wrap the result of getResponseBodyAsStream() in a
BufferedInputStream because I sometimes need to reset() and reread
some of the data. I read from the BufferedInputStream, which fills a
buffer from the underlying stream, which hits EOF and closes itself.
I get all the data I asked for from the BufferedInputStream, then
innocently call available(), which calls available() on the underlying
stream, which throws IOExecption. The workaround I use is to first
wrap the AutoCloseInputStream in an EofMonitoringInputStream, which
watches for -1 returns from read(), skip(), etc., and sets an internal
EOF flag that it uses to avoid calling methods on the closed stream.
This works ok, but is hardly elegant. I think this example
demonstrates that Java's stream architecture doesn't anticipate that
streams will close themselves in non-error situations.
I appreciate that some find the auto-close behavior useful, but I think
it should be optional (and documented).
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Roland Weber <ht...@dubioso.net>.
Hi Julius,
> Ditching releaseConnection() in favour of InputStream.close()???
> +1 +1 +1 !!!
It was before my time, but I think HttpClient used to work that
way until sometime around 2.0. Obviously it didn't work well, so
the releaseConnection was introduced to plug connection leaks.
> By "AutoClose", I guess you mean that it will close itself if the EOF
> is read? That makes sense.
Yes. AFAIK that already happens in HttpClient 3.x. We just don't
tell anybody, so keep it to yourself... ;-)
> On this note (things that annoy end-users)... I think
> MultiThreadedConnectionManager should become the default connection
> manager. If someone really knows what they're doing and doesn't want
> MTCM, they will have the ability to turn it off. But if someone
> doesn't know what they're doing, MTCM is much better for them. My
> personal "numbers" would be "max 30 connections", and "max 30
> connections per host" (not sure if that's how it still works).
30 connections per host can not be the default. RFC 2616 requires
that clients open no more than 2 connections per host. There are
exceptions for proxies, which are allowed to open 2 connections
per host per client.
I'm not sure about making TSCCM (which replaces MTHCM) the default.
Compared to SCCM (which will replace SHCM) it is a monster, and
there's currently two background threads involved. There's plenty
of people that follow the tutorial too strictly and keep creating
a new HttpClient for each request, or at least one for each thread.
Still, defaults are up for discussion.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Julius Davies <ju...@gmail.com>.
Ditching releaseConnection() in favour of InputStream.close()???
+1 +1 +1 !!!
By "AutoClose", I guess you mean that it will close itself if the EOF
is read? That makes sense.
On this note (things that annoy end-users)... I think
MultiThreadedConnectionManager should become the default connection
manager. If someone really knows what they're doing and doesn't want
MTCM, they will have the ability to turn it off. But if someone
doesn't know what they're doing, MTCM is much better for them. My
personal "numbers" would be "max 30 connections", and "max 30
connections per host" (not sure if that's how it still works).
yours,
Julius
On 2/10/07, Roland Weber <ht...@dubioso.net> wrote:
> Hi folks,
>
> I've reached a milestone with ClientRequestDirector. The replacement
> for HttpMethodDirector is now able to establish secure connections
> through a proxy. Along with that goes a first draft of HttpClient
> that uses the CRD. If you should look at the API at this stage, please
> remember that I'm _really_ still working on HTTPCLIENT-627 [1] and
> need the CRD as a sanity check of the connection management API.
>
> The rest of this mail is implementation details and an outlook.
>
> I did not "port" HttpMethodDirector to the new API, as I found the
> approach much too difficult. HMD is based on the HttpMethod concept
> and full of authentication related code, which is out of scope for
> the current problem. Instead I had HMD open in one editor window
> and implemented the CRD in another one, using a top-down approach
> to provide similar functionality. Wherever I left out functionality
> found in HMD, I put in a comment. Likewise when I felt there is
> an open question. The CRD code now looks as if more questions
> are posed than answered. It's a scrag, but I still feel that it
> is on the right track and that the missing functionality can be
> fitted nicely.
> To implement the route-building logic, I have added new classes that
> match my "HTTP route" idea. HttpRoute is meant as a replacement for
> HostConfiguration, which I would like to keep in a different role
> after HTTPCLIENT-618 [2]. ManagedClientConn and ClientConnManager
> are updated to use HttpRoute rather than HostConfiguration. TSCCM
> still uses HostConfig internally, as I don't want to start cleaning
> it up until there are testcases to ease Oleg's mind.
> There is one tiny little hole in the client API... connections can
> not yet be released. The examples send an OPTIONS request, which
> will generate a response without entity. In that case, the CRD
> releases the connection immediately.
> Connection release will be the next milestone. I'm thinking about
> an approach that relies on closing the input stream or entity rather
> than a releaseConnection method, as suggested in [4]. It will involve
> AutoCloseInputStream and check for connection re-use and some kind
> of extended interface (don't know which one yet) and I don't know
> what else. If possible, I will address HTTPCLIENT-589 [3] along the
> way, plus the questions I raised some weeks ago in [5]. After that,
> it's time for testcases and review.
>
> cheers,
> Roland
>
> [1] https://issues.apache.org/jira/browse/HTTPCLIENT-627
> [2] https://issues.apache.org/jira/browse/HTTPCLIENT-618
> [3] https://issues.apache.org/jira/browse/HTTPCLIENT-589
> [4]
> http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200508.mbox/%3c304447CF-0A71-49C2-871D-5476E9F75226@symphonious.net%3e
> [5]
> http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200701.mbox/%3c45B333F3.3010706@dubioso.net%3e
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> Just got the first cut at NIO SSL working on both the client and the
> server side. With the b**ch of NIO SSL almost off my back I would like
> to spend a few more days working on the outstanding HttpCore issues and
> then turn my attention to HttpConn and HttpAuth. I'll do my best to
> review the recent changes in HttpClient and give you some feedback by
> the next week.
Great.
> Feel free to go ahead and remove all deprecated classes if they are no
> longer of any use. The fewer classes to review the better.
I'd like to keep the ported versions of the two connection managers
for some time, until we've got test cases for the replacements. Actually,
there is not even a replacement yet for SimpleHttpConnectionManager. The
related interfaces and ported connection classes are required to keep the
stuff compiling. However, all 5 interfaces and classes are @deprecated
and not referenced from anywhere outside. You can safely ignore them for
the review.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpConn][HttpClient] status update
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2007-02-10 at 14:20 +0100, Roland Weber wrote:
> Hi folks,
>
> I've reached a milestone with ClientRequestDirector. The replacement
> for HttpMethodDirector is now able to establish secure connections
> through a proxy. Along with that goes a first draft of HttpClient
> that uses the CRD. If you should look at the API at this stage, please
> remember that I'm _really_ still working on HTTPCLIENT-627 [1] and
> need the CRD as a sanity check of the connection management API.
>
> The rest of this mail is implementation details and an outlook.
>
> I did not "port" HttpMethodDirector to the new API, as I found the
> approach much too difficult. HMD is based on the HttpMethod concept
> and full of authentication related code, which is out of scope for
> the current problem. Instead I had HMD open in one editor window
> and implemented the CRD in another one, using a top-down approach
> to provide similar functionality. Wherever I left out functionality
> found in HMD, I put in a comment. Likewise when I felt there is
> an open question. The CRD code now looks as if more questions
> are posed than answered. It's a scrag, but I still feel that it
> is on the right track and that the missing functionality can be
> fitted nicely.
> To implement the route-building logic, I have added new classes that
> match my "HTTP route" idea. HttpRoute is meant as a replacement for
> HostConfiguration, which I would like to keep in a different role
> after HTTPCLIENT-618 [2]. ManagedClientConn and ClientConnManager
> are updated to use HttpRoute rather than HostConfiguration. TSCCM
> still uses HostConfig internally, as I don't want to start cleaning
> it up until there are testcases to ease Oleg's mind.
> There is one tiny little hole in the client API... connections can
> not yet be released. The examples send an OPTIONS request, which
> will generate a response without entity. In that case, the CRD
> releases the connection immediately.
> Connection release will be the next milestone. I'm thinking about
> an approach that relies on closing the input stream or entity rather
> than a releaseConnection method, as suggested in [4]. It will involve
> AutoCloseInputStream and check for connection re-use and some kind
> of extended interface (don't know which one yet) and I don't know
> what else. If possible, I will address HTTPCLIENT-589 [3] along the
> way, plus the questions I raised some weeks ago in [5]. After that,
> it's time for testcases and review.
>
Hi Roland,
Just got the first cut at NIO SSL working on both the client and the
server side. With the b**ch of NIO SSL almost off my back I would like
to spend a few more days working on the outstanding HttpCore issues and
then turn my attention to HttpConn and HttpAuth. I'll do my best to
review the recent changes in HttpClient and give you some feedback by
the next week.
Feel free to go ahead and remove all deprecated classes if they are no
longer of any use. The fewer classes to review the better.
Cheers
Oleg
> cheers,
> Roland
>
> [1] https://issues.apache.org/jira/browse/HTTPCLIENT-627
> [2] https://issues.apache.org/jira/browse/HTTPCLIENT-618
> [3] https://issues.apache.org/jira/browse/HTTPCLIENT-589
> [4]
> http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200508.mbox/%3c304447CF-0A71-49C2-871D-5476E9F75226@symphonious.net%3e
> [5]
> http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200701.mbox/%3c45B333F3.3010706@dubioso.net%3e
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org