If I might inject a comment from a users viewpoint. We use HttpClient in our
VXML interpreter.  For any given fetch the application developer can provide
a "timeout" for the fetch.  When a method is generated we would need to pass
this timeout down to the connection the method uses.

Dennis Cook
BeVocal, Inc.
tel:  650-641-1424
fax: 650-210-9275


-----Original Message-----
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Monday, October 27, 2003 3:13 PM
To: Commons HttpClient Project
Subject: Re: SoTimeout setting


Mike, I see what you mean. Still, no matter how I look at it,
socket/connection timeout parameters on the HttpMethod level does not
seem right. 

Let's approach the issue from a different angle. You seem to dislike the
idea of exposing HttpConnection objects contained by
MultiThreadedHttpConnectionManager. What if we allowed
HttpConnectionParams instance(s) to be retrieved given a host
configuration (enumerated), not the HttpConnection instance(s)
itself(themselves)?

Besides, if I understand Fabio right, his issue is with inability to set
different socket/connection timeout parameters per connection. Setting
these parameters per method, if I understand things correctly, was
proposed merely as a work-around


On Mon, 2003-10-27 at 19:31, Michael Becke wrote:
> > Mike, Why do you think that providing an ability to enumerate of HTTP
> > connection would break this pattern?
> 
> I think that adding this functionality could be okay depending on the 
> use.  My worry is that it opens up a whole host of possible invalid 
> uses. This was not the concern I was trying to convey in my previous 
> statement though.  I intended to discourage major connection 
> configuration (timeout, send buffer, etc.) as part of the connection 
> retrieval/release process.  I think this should be handled by the 
> methods/HttpClient.
> 
> > What good would that make? You can always get HttpConnectionParams
> > from the HttpConnection. Am I missing something?
> 
> I was looking at this from the perspective of Fabio's question.  He 
> needs to be able to set the SO_TIMEOUT on a per method execution basis. 
>    Since he doesn't have direct access to the connection being used, my 
> though was that HttpClient could handle this configuration using passed 
> in params.  This is just one possible solution, I'm sure there are others.
> 
> Mike
> 
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to