hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: [PATCH] HttpClient/HttpMultiClient merge
Date Mon, 02 Dec 2002 14:50:09 GMT

On Monday, December 2, 2002, at 09:41 AM, Kalnichevski, Oleg wrote:
> 1) It's kind of sad to see yet another input stream wrapper. We 
> already have AutoCloseInputStream class. Now 
> ResponseAutoReleaseInputStream. This is kind of ugly (and potentially 
> error prone). I have already expressed my opinion that probably we 
> should simply enforce content buffering on all requests issued by the 
> multithreaded version of the HttpClient. Those people who do not want 
> response/request buffering (I fall into this category myself) should 
> use single-threaded version.

I agree, it is a bit of a hack.  The most reliable way to use the 
multithreaded version is to explicitly release the connection when done.

> 2) Please correct me if I am wrong, but currently there's no way to 
> abort a pending request from a different thread (usually GUI). That's 
> a major party breaker in my opinion. Again, it might make sense to 
> provide this kind of capability in the single-threaded version only.

Agreed, this is a problem I've encountered as well.  Perhaps we should 
put some work into this.  If implemented correctly it should be 
possible to implement this independent of which HttpConnectionManager 
is being used.  I'm guessing it will require additional functionality 
in the HttpMethod.

> Please let me know what you think
>
> Cheers
>
> Oleg
>
> -----Original Message-----
> From: Michael Becke [mailto:becke@u.washington.edu]
> Sent: Monday, December 02, 2002 5:57 AM
> To: Commons HttpClient Project
> Subject: Re: [PATCH] HttpClient/HttpMultiClient merge
>
>
> Hello all.  Sorry I haven't responded in a while.  I'll have time
> tomorrow to make the suggested changes and will post a new patch.
>
> Mike
>
> On Thursday, November 28, 2002, at 03:42 PM, Oleg Kalnichevski wrote:
>
>> Oops. My hands seem to be shaky. Sorry about my previous post
>>
>> Ortwin,
>> I have already proposed similar kind of protocol registry a while ago.
>> I
>> have already whipped up a few classes. If you decide to do it 
>> yourself,
>> I think it should also include a default port and a socket factory. I
>> do
>> agree that Mike's design would look even cooler if we did away with
>> that
>> awkward isSecure flag in HttpClient and HttpConnection methods and all
>> ugly code around it
>>
>> Cheers
>>
>> Oleg
>>
>>
>>
>> On Thu, 2002-11-28 at 20:45, Ortwin Gl├╝ck wrote:
>>> I finally reviewed your patch: Woah, GREAT WORK!
>>>
>>> Architecture looks clean. Tests run smoothly (except of 4 offline
>>> tests,
>>> but this could be a config or a temporary problem).
>>>
>>> There are a number of FIXME's. But this could easily cleaned up after
>>> the commit.
>>>
>>> I have some further enhancements but they do not block a commit:
>>>
>>> - in MultiThreadedHttpConnectionManager (what a class name!), have 
>>> you
>>> considered using a WeakHashMap instead of building this whole weak 
>>> ref
>>> stuff yourself? This JDK 1.2 compatible. I did not look at the 
>>> details
>>> so maybe it is not possible.
>>>
>>> - There are a lot of 'if (protocol.equalsIgnoreCase("HTTP")'
>>> statements.
>>> We could make a Protocol class like:
>>>
>>> public class Protocol {
>>>    private static Map protocols = new HashMap();
>>>    private String name;
>>>    private boolean secure;
>>>
>>>    static {
>>>       protocols.put("HTTP", new Protocol("http", false));
>>>       protocols.put("HTTPS", new Protocol("https", true));
>>>    }
>>>
>>>    private Protocol(String name, boolean secure) {
>>>      this.name = name;
>>>      this.secure = secure;
>>>    }
>>>
>>>    public static Protocol getProtocol(String name) {
>>>      return (Protocol) protocols.get(name);
>>>    }
>>> }
>>>
>>>
>>> In my opinion we can commit this.
>>>
>>> (A patch that works with the current CVS HEAD would be nice...)
>>>
>>>
>>> Odi
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <mailto:commons-httpclient-dev-unsubscribe@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <mailto:commons-httpclient-dev-help@jakarta.apache.org>
>> -- 
>> Oleg Kalnichevski <o.kalnichevski@dplanet.ch>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <mailto:commons-httpclient-dev-unsubscribe@jakarta.apache.org>
>> For additional commands, e-mail:
>> <mailto:commons-httpclient-dev-help@jakarta.apache.org>
>>
>
>
> --
> To unsubscribe, e-mail:   
> <mailto:commons-httpclient-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:commons-httpclient-dev-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:   
> <mailto:commons-httpclient-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:commons-httpclient-dev-help@jakarta.apache.org>
>


Mime
View raw message