Oleg Kalnichevski wrote:
A clear drawback to this approach is that the connection would need to
'know' what kind of request is being executed. Of course, this is just
design purism. Feel free to ignore me.
Oleg
Uhm... the connection does not need to know the method by name. It's
sufficient that
Just sending a quick note before I go to bed. I did some testing with
the example code and am now quite confident that HTCM is doing what it
should. I have not had time to add any DEBUG code but hopefully I will
get to it tomorrow.
Todd, one thing I noticed is that you are setting maxConnecti
>I've sent an email to the slide-dev group suggesting that they switch to
the 2.0 branch
Did they give any explaination or reply?
Regards,
Daniel
-Original Message-
From: Eric Johnson [mailto:[EMAIL PROTECTED]
Sent: Monday, 28 July, 2003 9:56 PM
To: Commons HttpClient Project
Subject:
Michael Becke wrote:
> Oleg Kalnichevski wrote:
>
* Perhaps the "isStale" check is unnecessary for methods that can
simply repeat themselves, for example, GET, HEAD, OPTION, TRACE.
For those methods, we could allow a "retry" to fix the problem.
For methods such as
This is a possibility I think. As Oleg mentioned I don't think we want
the connection to know about the method. We should be able to
accomplish something like this in the HttpMethod though. This assumes
that we can turn on/off the isStale test from outside the connection.
Mike
Oleg Kalniche
> >* Perhaps the "isStale" check is unnecessary for methods that can
> > simply repeat themselves, for example, GET, HEAD, OPTION, TRACE.
> > For those methods, we could allow a "retry" to fix the problem.
> > For methods such as POST and PUT, however, the isStale is probably
Eric,
I think there will be enough folks on this mailing list how would prefer
to have the redirect problem solved without breaking the API by a simple
drop-in replacement. They may well argue that what they are doing is
absolutely 'standard': just using redirects. Redirects should not be
considere
Todd,
I believe we have identified the reason for performance degradation
which is a stale connection check introduced in beta-1, not the
multi-threaded connection manager itself. The bogus log entries about
connection being created are caused by the connection wrapper class,
which is indeed creat
Dear Querent,
SSL is not implemented by HttpClient but is provided by an external
company such as Sun. HttpClient uses the SSL implementation that you
chose. How secure the SSL connections are is dependent on the algorithm
used. To be sure you should disable known weak algorithms in your SSL
i
Dear all,
I'd like to know how secure it is ssl in HttpClient.
I set up the host configuration using
HttpClient client = new HttpClient();
client.setStrictMode(true);
client.getHostConfiguration().setHost(LOGON_SITE, LOGON_PORT, "https");
while LOGON_SITE and LOGON_PORT is the address of http
Eric Johnson wrote:
Some possible alternatives:
* Only do the isStale check if the connection has been sitting in
the pool for a configurable amount of time. I'm guessing we could
choose a value here between 5 and 30 seconds without any
significant change in behavior, that is to
Actually Slide ships with a copy of Httpclient that manually has been
updated from time to time. The confusion arises just because
Httpclient is listed as a dependency of Slide in its Gump project
definition. This causes the nightly builds to fail.
I had my first look at Gump today and it seems to
Kalnichevski, Oleg wrote:
I would just make 'stale' connection check optional and off per default. Making the check pluggable would require too much of a change for what is essentially a release candidate. That should be better done as a part of 3.0 redesign IMO.
As I recall, the "isStale" functi
Oleg,
It doesn't matter too much to me either way. I've sent an email to the
slide-dev group suggesting that they switch to the 2.0 branch, but no
action has been taken yet.
Slide is an interesting test case, if only because it is representative
of how other clients are using HttpClient, at l
Hi Roland,
your observations 1,2&3 are correct.
I have no provision to get to a standalone IBM JDK.
Will be great if you can test it.
I am using WAS 4.0.3 that comes along with WSAD 4.0.3
for testing my code.
Here is a link that talks about using Sun JSSE with
WAS 4.0.3 :
http://www-106.ibm.co
Glad I could contribute. I've put together a test harness that reproduces
the connection issue. Unless I'm missing something, I'm pretty sure only a
single instance of MTCM is being accessed by the sending threads. Should I
send it to you and Mike directly rather than taking up bandwidth on the
> I agree that removing isStale() by default certainly fixes the
> performance problem. However, it makes MTCM somewhat unstable. The
> case where stale connections do not cause errors until read from will
> throw unrecoverable exceptions. Is this an acceptable alternative?
What if we keep '
Eric,
Of course, the patch can be rolled back. Alternatively we can leave
getResponseContentLength() method as is, and introduce an additional method that serve
similar function but returns long, not int.
But the whole point is that I really can't understand why Slide folks cannot just use
sta
On Monday, July 28, 2003, at 06:10 AM, Kalnichevski, Oleg wrote:
I would just make 'stale' connection check optional and off per
default. Making the check pluggable would require too much of a change
for what is essentially a release candidate. That should be better
done as a part of 3.0 redesi
Oleg,
Actually, I'm expecting that the redirect fix will probably not change
the way that webdavclient.jar works with HttpClient. I think the
redirect fix will only be a problem for some uses of the HttpClient library.
I would appreciate the change of the getResponseContentLength() back to
it
> I believe our only real option is to make isStale() optional and/or
> pluggable. Effective alternatives to isStale() have been thoroughly
> investigated and I think we can say that they do not exist, at least in
> a pre 1.4 environment. Does anyone have some new insight into this
> problem?
Hello NRR, (? :-)
I'll try to summarize the situation...
(just went through the mailing list archive)
1. your code works fine with Sun JDK 1.4 standalone
2. your code does not work with IBM JDK 1.3 in WSAD with IBM JSSE
3. your code does not work with IBM JDK 1.3 in WSAD with Sun JSSE
I'd like t
22 matches
Mail list logo
