RE: Question and comment about 3.0 API

2004-06-14 Thread Rezaei, Mohammad A. 
>So, currently 
>* The connection level socket timeout represents the default value
>settable upon connection initialization.
>* The optional method level socket timeout represents the 
>value settable
>upon method execution which overrides the default one.
>
>The old 2.0-style socket and connect timeout settings correspond to
>those of the connection manager (at least IMO).
>
>Let me now if you think that all this stuff does (or does not) make any
>sense

Hmmm.. With the 3.0 api, there are 3 levels: connection manager, http
client, http method.

With the 2.0 API, even though we wanted per method control, we used to call
httpClient.setTimeout();

The 2.0 code in HttpClient.java is very simple:

public synchronized void setTimeout(int newTimeoutInMilliseconds) {
this.timeoutInMilliseconds = newTimeoutInMilliseconds;
}

Specifically, we set it to 2 to "ping" a server and then set it to 0 to
execute the real call. It worked just fine (that is, it would never timeout
when set to zero).

With 3.0, the same call sequence broke: when we set the timeout to 0 after
it had been set to 2, it would actually timeout. The 3.0 code from
HttpClient:

public synchronized void setTimeout(int newTimeoutInMilliseconds) {
 
this.httpConnectionManager.getParams().setSoTimeout(newTimeoutInMilliseconds
);
}

I think if this code would use this.getParams() instead, it would work as
before. We've changed our code to use the httpMethod.setTimeout(), which
makes more sense; but I thought I'd bring it up as it is a non-trivial
change in the behavior.

>
>I reviewed the code found only two instances where the root exception
>was not propagated to the caller
>

Exception patch looks good to me. 
BTW, we haven't had any issues with Alpha 1. 

Thanks
Moh


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Question and comment about 3.0 API

2004-06-02 Thread Rezaei, Mohammad A. 
I'm testing out the new 3.0 API stuff and a couple of things have come up:

1) The new Params hierarchy is cool. One thing that seems a little strange
is constructs like:

method.getParams().setSoTimeout(2);

Seems a little unintuitive to call a set method after a get, especially
because there is also the setParams() method. In other words, it's not clear
if the above is the preferred method, or maybe:

Params p = method.getParams(); // should this be new Params(); ??
p.setX(x);
method.setParams(p);

2) The deprecated set parameter methods in HttpClient seem to set the
parameters on the connection manager. Why? Shouldn't those be set on the
HttpClientParams (specifically, see setSoTimeout()).

3) Minor point: We got an IO timeout exception and it didn't have the
underlying cause. I tracked it down to
HttpConnection.WrappedInputStream.handleException: the exception constructor
is not passing in the cause. Trivial to fix, but maybe a short review of the
code is in order to find such instances.

Thanks
Moh

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] 3.0 alpha 1 release

2004-05-14 Thread Rezaei, Mohammad A. 
+0

Thanks
Moh

>-Original Message-
>From: Michael Becke [mailto:[EMAIL PROTECTED] 
>Sent: Thursday, May 13, 2004 7:32 PM
>To: Commons HttpClient Project
>Subject: [VOTE] 3.0 alpha 1 release
>
>
>I propose that we mark the latest code in CVS HEAD as 3.0 alpha 1 and  
>proceed with a release.  Please vote as follows:
>
>---
>- 
>--
>  Vote:  HttpClient 3.0 alpha 1 release
>  [ ] +1 I am in favor of the release, and will help support it.
>  [ ] +0 I am in favor of the release, but am unable to help 
>support it.
>  [ ] -0 I am not in favor of the release.
>  [ ] -1 I am against this proposal (must include a reason).
>   
>---
>- 
>--
>
>
>-
>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]

RE: Streaming requests

2004-03-04 Thread Rezaei, Mohammad A. 
Please take a look at:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26070

The code attached to that bug report has been thoroughly tested and does
provide you with an OutputStream. Implement OutputStreamWriter and simply
write to the provided OutputStream. Do not close the stream.

Thanks
Moh

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
>Sent: Wednesday, March 03, 2004 4:42 PM
>To: Commons HttpClient Project
>Subject: Streaming requests
>
>
>I know there have been several discussions in regards to 
>streaming requests rather than buffering.  There have been 
>many suggestions on how to allow for streaming of requests 
>using Piped streams, etc, but I have come up against a 
>situation were it seems to be impossible to do with the 
>current architecture.  I am using JDOM to generate XML and 
>send it to the server using httpclient.  The problem I am 
>running into is that the xml can become large enough that 
>streaming would definately help on memory allocations. The 
>real stumbling block lies in the fact that JDOM expects an 
>output stream to write to and httpclient uses an input stream. 
> This would normally be a great place to use Piped streams but 
>in this instance it doesn't work.
>
>This example demonstrates the problem
>
>PipedInputStream pipedInputStream = new PipedInputStream(); 
>PipedOutputStream pipedOutputStream = new 
>PipedOutputStream(pipedInputStream);
>XMLOutputter output = new XMLOutputter();
>
>postMethod.setRequestBody(pipedInputStream);
>output.output(doc, pipedOutputStream);   // calling this outputs to the
>output stream but this hangs because the PipedInputStream is 
>not read until executeMethod int statusCode = 
>httpClient.executeMethod(postMethod);
>
>
>The problem here is that calling output of course hangs 
>because the PipedInputStream is not being read until 
>executMethod is called.  If there was access to an output 
>stream in postMethod this could be solved.  Does anyone have 
>any other ideas of how this could be accomplished?
>
>Thanks in advance for any help.
>
>
>
>-
>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]

RE: [RFE] provide request entities in a more abstract way

2004-02-26 Thread Rezaei, Mohammad A. 
I see. If we limit the retries to 401 and 407, we're safe, per the RFC:
401:
"The client MAY repeat the
   request with a suitable Authorization header field"
407:
"The
   client MAY repeat the request with a suitable Proxy-Authorization
   header field "

Most of the other 40x are fatal and should not be retried.
So a simple interface (3 methods: isRetriable(), resetStream(),
getInputStream() ??) sounds like a good idea.

Thanks
Moh

>-Original Message-
>From: Roland Weber [mailto:[EMAIL PROTECTED] 
>Sent: Thursday, February 26, 2004 10:13 AM
>To: Commons HttpClient Project
>Subject: RE: [RFE] provide request entities in a more abstract way
>
>
>Hello Moh,
>
>you are assuming preemptive authentication.
>In general, authentication is triggered by a 40x
>response from the server, which means the
>request has already been sent.
>
>best regards,
>  Roland
>
>
>
>
>
>"Rezaei, Mohammad A." <[EMAIL PROTECTED]>
>26.02.2004 15:57
>Please respond to "Commons HttpClient Project"
> 
>To: "'Commons HttpClient Project'" 
><[EMAIL PROTECTED]>
>cc: 
>Subject:RE: [RFE] provide request entities in a more 
>abstract way
>
>
>Both authentication and closed connections should occur long before we 
>read
>the input stream to send the request body. So why would you 
>want to reset the stream?
>
>Thanks
>Moh
>
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [RFE] provide request entities in a more abstract way

2004-02-26 Thread Rezaei, Mohammad A. 
Both authentication and closed connections should occur long before we read
the input stream to send the request body. So why would you want to reset
the stream?

Thanks
Moh

>-Original Message-
>From: Ortwin Glück [mailto:[EMAIL PROTECTED] 
>Sent: Thursday, February 26, 2004 9:56 AM
>To: Commons HttpClient Project
>Subject: Re: [RFE] provide request entities in a more abstract way
>
>
>Rezaei, Mohammad A. wrote:
>> This is a bad idea. The HTTP RFC (2616) explicitly forbids auto 
>> retries:
>> 
>> "Non-idempotent methods or sequences
>>MUST NOT be automatically retried, although user agents 
>MAY offer a
>>human operator the choice of retrying the request(s). "
>> 
>> So if retries are not good, then what's the point of the interface?
>> 
>> Thanks
>> Moh
>
>Moh,
>
>please note that I refer "retry" as resending the request if it fails 
>due to
>  a) authentication
>  b) closed connection from the pool
>
>HttpClient already has this functionality, but it is just not possible 
>to use it with unbuffered request entities.
>
>O.
>
>-
>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]

RE: [RFE] provide request entities in a more abstract way

2004-02-26 Thread Rezaei, Mohammad A. 
>From: Ortwin Glück
>Sent: Thursday, February 26, 2004 6:27 AM
>To: Commons HttpClient Project
>Subject: Re: [RFE] provide request entities in a more abstract way
>
>
>> In the second case,
>> I would add something like isRepeatable() to handle cases 
>where it is 
>> indeed not possible to read the data twice.
>
>My point was to force the user to make it repeatable. Yet, I 
>am not sure 
>if that is a good idea. You may be right that not all (especially 
>streaming) data in the world may be available twice.

This is a bad idea. The HTTP RFC (2616) explicitly forbids auto retries:

"Non-idempotent methods or sequences
   MUST NOT be automatically retried, although user agents MAY offer a
   human operator the choice of retrying the request(s). "

So if retries are not good, then what's the point of the interface?

Thanks
Moh


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: streaming request body

2004-02-23 Thread Rezaei, Mohammad A. 
Have a look here:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26070

Thanks
Moh


-Original Message-
From: John Keyes [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 23, 2004 3:49 PM
To: Commons HttpClient Project
Subject: Re: streaming request body


Guys,

A colleague pointed out to me that this does not in fact resolve the  
situation.  The solutions pointed out allow me to read the attachment  
as a stream.  The contents are still held in memory prior to writing it  
on the wire.  To fully support this you would need access to the  
OutputStream.

If we could pass a HttpClient to the HttpMethod then we could get  
access to the output stream via the getRequestOutputStream method.

I don't understand the connection pooling argument.  I thought it  
should be a user preference whether to have connection pooling.

Any ideas on this?
-John K

On 23 Feb 2004, at 13:02, Kalnichevski, Oleg wrote:

>
> John,
>
> HttpClient's entity enclosing methods (POST, PUT) do support content
> streaming when (1) the content length does not need to be  
> automatically calculated or (2) chunk-encoding is used
>
> Please refer to the following sample applications for details
>
> Unbuffered post:
>
> http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/
> httpclient/src/examples/UnbufferedPost.java?content- 
> type=text%2Fplain&rev=1.2.2.1
>
> Chunk-encoded post:
>
> http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/
> httpclient/src/examples/ChunkEncodedPost.java?content- 
> type=text%2Fplain&rev=1.4.2.1
>
> Hope this helps
>
> Oleg
>
>
> -Original Message-
> From: John Keyes [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 23, 2004 13:54
> To: [EMAIL PROTECTED]
> Subject: streaming request body
>
>
> Hi,
>
> I notice you have separated out the functions of the connection and 
> the content creation. So the code must be something like
>
> HttpClient client = new HttpClient( url );
> HttpMethod method = new GetMethod();
> method.setRequestHeader( ... ); ...
> method.setRequestBody( ... );
> client.execute( method );
>
> If I want to send a large attachment and I don't want it all to be in 
> memory then I can't do it.  The issue is that you have to write your 
> data to the HttpMethod. The HttpMethod doesn't know where to then 
> write this data until you call execute and pass the client which has 
> the connection to write to. So there isn't really a way around this 
> because of the separation of the connection from the HttpMethod.
>
> So my question is, is there a way to stream the request body rather 
> than having to store the request in memory prior to writing it on the 
> wire.
>
> Thanks,
> -John K
>
>
> -
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:  
> [EMAIL PROTECTED]
>
>
> *** 
> 
> The information in this email is confidential and may be legally  
> privileged.  Access to this email by anyone other than the intended  
> addressee is unauthorized.  If you are not the intended recipient of  
> this message, any review, disclosure, copying, distribution,  
> retention, or any action taken or omitted to be taken in reliance on  
> it is prohibited and may be unlawful.  If you are not the intended  
> recipient, please reply to or forward a copy of this message to the  
> sender and delete the message, any attachments, and any copies thereof  
> from your system.
> *** 
> 
>
> -
> 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]

RE: JIRA vs Bugzilla issue

2004-01-21 Thread Rezaei, Mohammad A. 
Is there an automatic way to move the current issues over to JIRA? The open
bugs are important, but the closed ones also contain a wealth of
information.

Thanks
Moh

-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 21, 2004 6:41 AM
To: Jakarta Commons HttpClient mailing list
Subject: Re: JIRA vs Bugzilla issue


Folks,
What say you, do we migrate HttpClient issue tracking to JIRA or do we stay
with Bugzilla? Please let me know your opinion.

Oleg


On Tue, 2004-01-13 at 20:29, Oleg Kalnichevski wrote:
> Shall I apply? Any strong opinions to not migrate to JIRA?
> 
> Oleg
> 
> 
> On Tue, 2004-01-13 at 20:01, Michael Becke wrote:
> > Yes, I've been following that discussion as well.  I'm definitely
> > interested in making the switch to JIRA.  Bugzilla has served us pretty 
> > well, but I find it somewhat unwieldy at times.
> > 
> > Mike
> > 
> > On Jan 13, 2004, at 11:44 AM, Kalnichevski, Oleg wrote:
> > 
> > > There's currently a rather animated discussion 'JIRA vs Bugzilla'
> > > going on the commons-dev mailing list. Personally I do not have a 
> > > strong option on this issue. There's one thing, though, that makes me 
> > > bring it up here: we are facing the need to massively restructure 
> > > Bugzilla content related to HttpClient due to the change of the next 
> > > release version from 2.1 to 3.0. (Funny enough, the way versioning is 
> > > handled in Bugzilla is being one of the most frequently mentioned 
> > > motivators for migration to JIRA). My point here, if we ever wanted to

> > > migrate to JIRA, now would be the right moment.
> > >
> > > Let me know what you think (let us not turn it into a religious 
> > > war
> > > currently being waged on the commons-dev, though)
> > >
> > > 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]

RE: [VOTE] 2.0 RC3 Release

2004-01-13 Thread Rezaei, Mohammad A. 
+0

Thanks
Moh

-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 13, 2004 11:43 AM
To: Commons HttpClient Project
Subject: RE: [VOTE] 2.0 RC3 Release


+1

-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 13, 2004 17:29
To: Commons HttpClient Project
Subject: [VOTE] 2.0 RC3 Release


I propose that we mark the latest code in CVS HTTPCLIENT_2_0_BRANCH as  
RC3 and proceed with a release.  Please vote as follows:

 
--
  Vote:  HttpClient 2.0 RC3 release
  [ ] +1 I am in favor of the release, and will help support it.
  [ ] +0 I am in favor of the release, but am unable to help support it.
  [ ] -0 I am not in favor of the release.
  [ ] -1 I am against this proposal (must include a reason).
   
 
--


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

RE: 2.0rc3 before XMas?

2003-12-17 Thread Rezaei, Mohammad A. 
Oleg, I do agree that the bug as described in bugzilla is not serious for
the reasons you mention below. However, if you recall our discussion
(http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-httpclient-dev@
jakarta.apache.org&msgNo=5279 ) the serious issue is caused by the
underlying socket remaining open. Since there is already a bit of confusion,
I think I'll go ahead and open a new bug with the correct description of the
serious issue:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25592

The funny thing is, fixing the serious bug will automatically fix the
non-serious one.


Thanks
Moh


-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 16, 2003 5:38 PM
To: Commons HttpClient Project
Subject: RE: 2.0rc3 before XMas?


Mohammad,
I guess I have at least half a dozen of outstanding patches at the moment
;-) so it is about a matter of priority. I do not mind committing the patch,
however, I would like to have this one committed first:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25529

And I would still like to go through the regular review process for the 2.1
branch and to secure an OK from at least another committer. In my opinion
the bug is not significant enough to be rushed. As to patching 2.0, I am not
sure it is warranted. After all one MUST call HttpMethod#releaseConnection
in order to ensure the connection release even if an exception is thrown
during the method execution.

Any strong option on this?

Oleg


On Tue, 2003-12-16 at 23:11, Rezaei, Mohammad A. wrote:
> I would appreciate a resolution to this bug: 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25370
> 
> I personally think that the patch seems trivial enough that going for 
> 2.0 (instead of 2.1+) is probably warranted.
> 
> Oleg: There were no comments from the list, so I assume there was 
> nothing glaringly wrong with our approach. Do you mind submitting the 
> patch you wanted?
> 
> Thanks
> Moh
> 
> -Original Message-
> From: Michael Becke [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 16, 2003 5:02 PM
> To: Commons HttpClient Project
> Subject: Re: 2.0rc3 before XMas?
> 
> 
> I would love to.  Funny, I was just thinking the same thing.  We have
> two options that I can see:
> 
>   - Create a full fledged rc 3 release.  After a week or so, if there
> are no major bugs, we could retag it as 2.0 final.
>   - Create a unofficial release and publish it from one of our personal 
> apache accounts.  This one could then be tested thoroughly and released 
> as 2.0 final after everyone is happy that it works.
> 
> My preference is for the second method, mostly because it avoids going
> through the whole offical release process twice.  Perhaps I am just 
> being lasy, but I think if we are comfortable that authentication and 
> proxying are working correctly then 2.0 is ready.  We always have the 
> option of a 2.0.1 if anything major is missed.
> 
> What does everyone think?
> 
> Mike
> 
> Oleg Kalnichevski wrote:
> 
> > Folks,
> > Any chance of getting 2.0rc3 out of the door before XMas? What do 
> > you
> > think?
> > 
> > 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]

RE: 2.0rc3 before XMas?

2003-12-16 Thread Rezaei, Mohammad A. 
I would appreciate a resolution to this bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25370

I personally think that the patch seems trivial enough that going for 2.0
(instead of 2.1+) is probably warranted.

Oleg: There were no comments from the list, so I assume there was nothing
glaringly wrong with our approach. Do you mind submitting the patch you
wanted?

Thanks
Moh

-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 16, 2003 5:02 PM
To: Commons HttpClient Project
Subject: Re: 2.0rc3 before XMas?


I would love to.  Funny, I was just thinking the same thing.  We have 
two options that I can see:

  - Create a full fledged rc 3 release.  After a week or so, if there 
are no major bugs, we could retag it as 2.0 final.
  - Create a unofficial release and publish it from one of our personal 
apache accounts.  This one could then be tested thoroughly and released 
as 2.0 final after everyone is happy that it works.

My preference is for the second method, mostly because it avoids going 
through the whole offical release process twice.  Perhaps I am just 
being lasy, but I think if we are comfortable that authentication and 
proxying are working correctly then 2.0 is ready.  We always have the 
option of a 2.0.1 if anything major is missed.

What does everyone think?

Mike

Oleg Kalnichevski wrote:

> Folks,
> Any chance of getting 2.0rc3 out of the door before XMas? What do you 
> think?
> 
> 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]

RE: [Bug 25370] - exception during writeRequest leaves the conn ection un-released

2003-12-11 Thread Rezaei, Mohammad A. 
I'm forwarding this to the list. The conversation that originally started on
Bug 25370 took a turn and uncovered a potentially critical problem. The
original bug was about releasing the connection back to the pool. This
conversation is about closing the underlying socket under the same
situation. I'm not sure if we want to keep track of it under the same bug or
a new one. 

The good news is, the solution is fairly simple and Oleg lists it below. The
same code can fix Bug 25370 if we release the connection after closing the
socket.

Thanks
Moh
P.S. This is my second attempt at sending this to the list. Hope it's not a
duplicate.

-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 10, 2003 4:54 PM
To: Rezaei, Mohammad A.
Subject: RE: [Bug 25370] - exception during writeRequest leaves the conn
ection un-released


Mohammad,
I do not think we should be taking this discussion off-line. I'd really
appreciate if you posted your comments to the but report. Some other folks
may have something to contribute, for instance, Mike who actually authored
Multithreaded connection manager 

On Wed, 2003-12-10 at 22:28, Rezaei, Mohammad A. wrote:
> handleException is only called when inside the WrapperOutputStream
> methods. A *read* failure while sending a file (or a runtime 
> exception, etc) will not be caught here. Am I missing something?
> 

You certainly have a point here. I guess HttpMethoDirector#executeMethod may
simply do the following

try {
 execute
}
catch (IOException e) {
  // close the damn thing
}
catch (RuntimeException e) {
  // close the damn thing
}
finally {
  // see if it is safe to release connection 
  // (no unread response content left 
  // or not response body not expected) 
}

Would you like to whip up a patch or shall I do it?

Cheers

Oleg

> Thanks
> Moh
> 
> -Original Message-
> From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 10, 2003 4:24 PM
> To: Rezaei, Mohammad A.
> Subject: Re: [Bug 25370] - exception during writeRequest leaves the conn
> ection un-released
> 
> 
> 
> On Wed, 2003-12-10 at 22:07, Rezaei, Mohammad A. wrote:
> > 9M. Reusing that socket will have very unpredictable results (it 
> > acts
> > like a black hole and won't throw any exception unless a timeout is 
> > specified). It would be prudent to close the socket on an IOException 
> > or a RuntimeException. Do you agree? Should I file this under a 
> > separate bug or under this one?
> > 
> 
> Mohammad,
> The wrapper class should take of that:
> 
> /**
>  * Closes the connection and conditionally converts exception 
> to recoverable.
>  * @param ioe the exception that occurred
>  * @return the exception to be thrown
>  */
> private IOException handleException(IOException ioe) {
> // keep the original value of used, as it will be set to 
> false by close().
> boolean isRecoverable = HttpConnection.this.used;
> HttpConnection.this.close();
> if (ioe instanceof InterruptedIOException) {
> return new IOTimeoutException(ioe.getMessage()); 
> } else if (isRecoverable) {
> LOG.debug(
> "Output exception occurred on a used connection.
> Will treat as recoverable.", 
> ioe
> );
> return new HttpRecoverableException(ioe.getMessage(),
> ioe);
> } else {
> return ioe;
> }
> }
> 
> Cheers,
> 
> Oleg
> 
> 
> 
> 
> > Thanks
> > Moh
> > 
> > --- Additional Comments From [EMAIL PROTECTED]  2003-12-10 20:01
> > ---
> > > if (CAUSE_RANDOM_ERROR) if (Math.random() > ERROR_RATE) throw new 
> > > IOException("Random error, for testing only!");
> > 
> > OK. I see.
> > 
> > > From reading the code, it seems the outputstream is wrapped
> > > insideWrappedOutputStream which rethrows any exceptions *inside its
> > methods*
> > > asrecoverable. There are two problems with this approach.
> > 
> > Mohammad, actually that is that way it is supposed to be. 
> > IOException
> > thrown when retrieving request content or runtime exceptions are not 
> > recoverable HTTP transport exceptions and should not be treated as 
> > such
> > 
> > > Thanks for the clarification. You still have to be extremely 
> > > careful if you enable auto recovery on write.
> > 
> > Agreed. I personally am not in favour of having auth-recovery
> > activated per defaul