Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <E705D2E9BE54784981F1862F701ADE7901763165@edmexm01>
From: Gustavo Hexsel <ghexsel@sagebrushcorp.com>
To: 'Jakarta Commons Users List' <commons-user@jakarta.apache.org>
Subject: RE: [HttpClient] getting the http connection or setting the param
	 s
Date: Fri, 8 Oct 2004 15:57:21 -0500 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

  Hi Oleg, 

  Wouldn't that coupling be necessary anyway for writing a
HttpMethod#setActualSocketTimeout method?

  []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