hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Connection closes and SharedInputBuffer shutdown
Date Fri, 29 Aug 2008 13:15:46 GMT
On Fri, 2008-08-29 at 18:14 +0530, Asankha C. Perera wrote:
> Hi Oleg
> I am looking at the SharedInputBuffer, for which Jason has proposed some 
> fixes (https://issues.apache.org/jira/browse/HTTPCORE-172), with which I 
> agree.
> Sometime back my original fix for it, was to not shutdown the buffer, 
> while it had data which was not yet read as:
> public void shutdown() {
>         if (this.shutdown) {
>             return;
>         }
>         if (!hasData() && this.endOfStream) {
>             this.shutdown = true;
>             synchronized (this.mutex) {
>                 this.mutex.notifyAll();
>             }
>         }
>     }
> However, I think Jasons version of the fix as described in the above 
> JIRA is better. Do you have any comments on these approaches?

Hi Asankha,

Yes, I posted my comments to the issue report. Generally, I am fine with
the proposed changes as long as synchronization of the threading unsafe
#hasData() method is taken care of. However, I have an alternative
solution to propose which preserves the existing semantics of the
#shutdown() method and solves the problem by adding new #close() method.
Please take a look. Ideally I would like to be able to differentiate
between an abnormal shutdown and an orderly closure cases.  

> However, even after the above version of the fix, Eric reported that he 
> saw the same resultant error usually caused by this bug in his 
> production environment.
> I was looking at the following code:
> public int consumeContent(final ContentDecoder decoder) throws IOException {
>         if (this.shutdown) {
>             return -1;
>         }
> and wondering why you have the above if condition.. is it even remotely 
> possible for a consumeContent() call (triggered by an inputReady() to 
> come after a closed() call? If so, we may need another fix here..

The initial idea was that buffers get shut down only in case of a
non-recoverable problem such as I/O failure, so their internal state
were no longer consistent / valid. If we change the semantics of the
#shutdown() method we may also need to change the above behavior.  



> thanks
> asankha

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message