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]