On Fri, 2004-10-08 at 22:57, Gustavo Hexsel wrote: > Hi Oleg, > > Wouldn't that coupling be necessary anyway for writing a > HttpMethod#setActualSocketTimeout method?
Gustavo, HttpMethod is already coupled with HttpConnection and HttpMethodParams. That's why it is much easier to add HttpMethod#setActualSocketTimeout method, which, however, would produce quite an ugly and confusing API. On the other hand the tight coupling between HttpMethodParams and HttpMethod / HttpConnection is even worse and completely defeats the new preferences API we have built so far. I really would rather wait with resolution of this problem until release 4.0 Oleg > > []s Gustavo > > > -----Original Message----- > From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] > Sent: October 8, 2004 2:46 PM > To: Jakarta Commons Users List > Subject: RE: [HttpClient] getting the http connection or setting the > param s > > > Gustavo, > This is not that simple. HttpMethodParams then would need to 'know' > about underlying HttpConnection, which would effectively mean coupling > it with HttpMethodBase and HttpConnection classes or providing some kind > of notification mechanism based on "observable" pattern. > > Oleg > > On Fri, 2004-10-08 at 22:36, Gustavo Hexsel wrote: > > Can't you guys just propagate the SO_TIMEOUT to the socket when > > setSoTimeout is called? Then the api does not need to change, only a bit > of > > the javadoc. It should not harm other users either, for if they are > setting > > it before it won't make a difference, and if they are setting it after the > > method executed, they are probably expecting the socket to comply with the > > change. Only the javadoc makes it explicit that the socket does not get > > changed until the method is executed again. > > > > []s Gustavo > > > > > > -----Original Message----- > > From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] > > Sent: October 8, 2004 2:32 PM > > To: Jakarta Commons Users List > > Subject: RE: [HttpClient] getting the http connection or setting the > > param s > > > > > > On Fri, 2004-10-08 at 22:20, Gustavo Hexsel wrote: > > > I actually want it more fine-grained than that, I want the SO_TIMEOUT > to > > > be different for each read (with the remaining time until time-out). I > > > posted a RFE for it, as Oleg suggested. > > > > Mike, this does seem like a legitimate requirement. Currently SO_TIMEOUT > > always remains constant through the entire HttpMethod lifespan. When > > dealing with larger responses one may need a finer control. It is not > > going to be difficult to implement. But unfortunately it is quite likely > > to result in an uglier API and tons of confused people. Something like > > HttpMethod#setActualSocketTimeout. > > > > Oleg > > > > > > > > Thank you all, guys! > > > > > > []s Gustavo > > > > > > > > > > > > -----Original Message----- > > > From: Michael Becke [mailto:[EMAIL PROTECTED] > > > Sent: October 8, 2004 12:13 PM > > > To: Jakarta Commons Users List > > > Subject: Re: [HttpClient] getting the http connection or setting the > > > param s > > > > > > > > > Yes, setting the timeout will not effect methods that have already been > > > executed. Even if it did, I'm not sure it would help much in this case. > > > > Gustavo, is sounds like you want a per method execution timeout. The > > > SO_TIMEOUT is for each individual read operation at the socket level. > > > > > > Mike > > > > > > Oleg Kalnichevski wrote: > > > > On Fri, 2004-10-08 at 19:11, Gustavo Hexsel wrote: > > > > > > > >> I already have a reference to the input stream - the method was > > already > > > >>executed. Will it still set the timeout for the socket? > > > >> > > > >> []s Gustavo > > > > > > > > > > > > > > > > All right. I see. It will not. Feel free to file a feature request. It > > > > is still not too late to have this included into the 3.0 release > > > > > > > > Oleg > > > > > > > > > > > > > > > >> > > > >>-----Original Message----- > > > >>From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] > > > >>Sent: October 8, 2004 11:07 AM > > > >>To: 'Jakarta Commons Users List' > > > >>Subject: RE: [HttpClient] getting the http connection or setting the > > > >>param s > > > >> > > > >> > > > >>On Fri, 2004-10-08 at 17:41, Gustavo Hexsel wrote: > > > >> > > > >>> Hi Michael, > > > >>> > > > >>> thanks for the prompt answer. > > > >>> > > > >>> By connection params I meant the HttpConnection.setParams(). I saw > > the > > > >>>javadoc for that class, and it states that if I set SO_TIMEOUT there, > > it > > > >>>will change the value for open sockets as well. If I just set the > > method > > > >>>parameters, by calling HttpBaseMethod.setParams(), it will change the > > > >>>parameter only when opening new sockets. > > > >> > > > >>Gustavo, > > > >>This is not the case. HttpClient resets SO_TIMEOUT every time the > > > >>connection is obtained from the connection manager, because the > > > >>connection can be still left open ('alive') and may contain an > arbitrary > > > >>SO_TIMEOUT value set by the previous method. > > > >> > > > >>When SO_TIMEOUT is defined at the HTTP method, the method value is > used, > > > >>otherwise, default value defined at the HTTP connection/connection > > > >>manager level is used. > > > >> > > > > > > >>http://jakarta.apache.org/commons/httpclient/3.0/xref/org/apache/commons/h > > > tt > > > >>pclient/HttpMethodDirector.html#379 > > > >> > > > >>Oleg > > > >> > > > >> > > > >>--------------------------------------------------------------------- > > > >>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] > > > > > > --------------------------------------------------------------------- > > > 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] > > --------------------------------------------------------------------- > 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]
