> 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, Allow me try to clarify a few things. I assume you are saying that certain methods that need to fetch larger content may take longer to execute and therefore need a different (perhaps greater) timeout value. Is that right? The problem is that SO_TIMEOUT value does not help here at all. SO_TIMEOUT does not define the maximum duration a method may take. Please correct me if am wrong, but SO_TIMEOUT defines the maximum period of time a read operation may block the socket when expecting input. In other words, SO_TIMEOUT defines the maximum period of inactivity between two consecutive reads. As such SO_TIMEOUT simply does not make sense on a per method basis. It is a socket (connection) property, not that of a method. Regards, Oleg -----Original Message----- From: Dennis Cook [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 01:43 To: 'Commons HttpClient Project' Subject: RE: SoTimeout setting 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
