commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@bluewin.ch>
Subject RE: [HttpClient] getting the http connection or setting the param s
Date Sat, 09 Oct 2004 14:18:33 GMT
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:olegk@bluewin.ch]
> 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:olegk@bluewin.ch]
> > 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:becke@u.washington.edu]
> > > 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:olegk@bluewin.ch]
> > > >>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: commons-user-unsubscribe@jakarta.apache.org
> > > >>For additional commands, e-mail: commons-user-help@jakarta.apache.org
> > > >>
> > > >>---------------------------------------------------------------------
> > > >>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > > >>For additional commands, e-mail: commons-user-help@jakarta.apache.org
> > > >>
> > > > 
> > > > 
> > > > 
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> > > > 
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> > > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message