1) This is what I mean: 
http://hc.apache.org/httpclient-3.x/performance.html#Connection_persistence
In other words, not relying on the SO to release connections. Most of the time it's not a big deal, but in some cases this can be annoying
2) You are welcome https://issues.apache.org/jira/browse/OFBIZ-4430. Maybe it's 
not harder indeed...

Jacques

From: "BJ Freeman" <bjf...@free-man.net>
Ok a longer version of my terse reply.
there are two concerns in this thread you brought up.
1) TIMENOUT
2) implementing a different package that does not support the newer
java.nio.channel like the APJ does.
#1 is something than if you set to long it will waste response time, on
a bad connection, if to short will have the effect in the Email.
when I started in 96 the latency of the internet was uder 100 ms max.
Now the latency of the net is upwards of what used to be considered
intoloralbe latency (200 ms).
On top of that you have the Server response time which during the
Holidays gets really long so you will time out before the server
responds causing resends that only bog down the server more.
the above is a long winded way of saying your time out has to change
with the conditions.
#2 in looking at the http library they are still using the java.net for
connection. So in my estimation, we do a re-factor of ofbiz to java.nio
and fix the httpclient we have.


Jacques Le Roux sent the following on 9/17/2011 9:13 AM:
I'm resurrecting this thread because, as outlined by this other thread
http://markmail.org/message/j4s6tq2ccit3wtbf, unlike Apache
HttpClient, OFBiz's is not closing connections.
I have not the time at the moment to replace it, but I'd like to do so
in October or November. I will open a Jira then (this message
more as a self reminder...)

Interesting link also
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html

Jacques

From: "BJ Freeman" <bjf...@free-man.net>
I have done more investigation, and found the methods I depend on in the
jar come from java 1.31. in looking at the current httpclient, it does
not support the code I have.
I am not sure what I will do at this point but for the trunk it would be
best to use the current httpclient.
I am still going thru the current httpclient class in ofbiz to figure
out how is would be used, mostly in communication with third parties.

Adrian Crum sent the following on 10/23/2008 2:39 PM:
I was thinking we could deprecate the constructors, and point people to
the new class.

-Adrian

BJ Freeman wrote:
just as a note there are methods in the ofbiz one that work with ofbiz
structure. I would like to review those to see if they can be used
I guess the proper steps is to depreciate those.

BJ Freeman sent the following on 10/23/2008 1:47 PM:
works for me.
it has been moved around
found it under
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module-client/




Adrian Crum sent the following on 10/23/2008 1:37 PM:
I'd rather switch to the commons one and eliminate the OFBiz one.
It's
only used in one or two places, so it wouldn't be a difficult
change to
make.

-Adrian

BJ Freeman wrote:
I have been looking at HTMLUnit since our last conversation, for
implementing user test screens.
this is more that there are two HttpClient classes and the ofbiz
one is
used in the framework.
it seemed the simplest solution would be to use implements to
append the
 apache one to the ofbiz one thus making the ofbiz one more
versatile.

Adrian Crum sent the following on 10/23/2008 1:06 PM:
I would recommend using any suitable replacement for the OFBiz
HttpClient - it is very rudimentary.

If you need an HTTP client that handles cookies and JavaScript,
then
take a look at HTMLUnit - http://htmlunit.sourceforge.net. I used
it in
my mashup POC code -
https://issues.apache.org/jira/browse/OFBIZ-1873.

-Adrian

BJ Freeman wrote:
while working with yahoo API
I came accross the org.apache.commons.httpclient.HttpClient;
which has more functionality than the ofbiz HttpClient
is there any problem with making the ofbiz an HttpClient
implementation
of the apache?











Reply via email to