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.
Cheers
Oleg
> thanks
> asankha
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
