You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Jason Walton (JIRA)" <ji...@apache.org> on 2008/09/10 21:31:44 UTC
[jira] Commented: (HTTPCORE-172) SharedInputBuffer stops returing
data to reading thread once shutdown is called
[ https://issues.apache.org/jira/browse/HTTPCORE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629926#action_12629926 ]
Jason Walton commented on HTTPCORE-172:
---------------------------------------
Hmm... And we need a notifyAll() in close.
> SharedInputBuffer stops returing data to reading thread once shutdown is called
> -------------------------------------------------------------------------------
>
> Key: HTTPCORE-172
> URL: https://issues.apache.org/jira/browse/HTTPCORE-172
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0-beta2
> Environment: Synapse 1.2
> Reporter: Jason Walton
> Fix For: 4.0-beta3
>
> Attachments: sharedbuf.patch
>
>
> This problem won't happen in Synapse 1.2 without the fix I proposed for https://issues.apache.org/jira/browse/SYNAPSE-415 in ClientHandler.java.
> To briefly recap: If a ClientWorker attempts to read from a SharedInputBuffer, but no data is availabled, SharedInputBuffer.read() will call into waitForData(). If the next event to the ClientHandler is a "closed()" event, then the ClientHandler will remove its references to the SharedInputBuffer. At this point in time, the ClientWorker is left waiting for data forever. The fix I proposed for SYNAPSE-415 was to call into SharedInputBuffer.shutdown() from ClientHandler.closed(), as this will send a notify to the SharedInputBuffer and wake up the ClientWorker.
> This seemed like a good fix at the time, but now I'm running into this from the "other side", so to speak. Suppose the ClientWorker is a bit late in reading the stream.
> 1) I/O Dispatcher thread receives data from the socket, and calls ClientHandler.inputReady(), which in turn calls SharedInputBuffer.consumeContent(). This puts some data into the SharedInputBuffer's buffer.
> 2) I/O Dispathcer thread sees the socket close, and so calls ClientHandler.closed(). This calls into SharedInputBuffer.shutdown().
> 3) The ClientWorker thread calls into SharedInputBuffer.read(), which starts out with:
> if (this.shutdown) {
> return -1;
> }
> The result is that the ClientWorker will erroneously think we never got a reply.
> A similar issue exists in SharedOutputBuffer, except here you would have to call "shutdown()" followed by "produceContent()". Since both of these methods are called from the I/O dispatcher side, this wouldn't make a lot of sense (how can we produce content for a socket which is closed?). I suppose someone might call "shutdown()" instead of "writeCompleted()" in some sort of error scenario on the worker side? Probably not really worth worrying about.
> Here's my proposed fix (comments welcome, since I don't know this code as well as I could):
> Index: module-nio/src/main/java/org/apache/http/nio/util/SharedInputBuffer.java
> ===================================================================
> --- module-nio/src/main/java/org/apache/http/nio/util/SharedInputBuffer.java (revision 689999)
> +++ module-nio/src/main/java/org/apache/http/nio/util/SharedInputBuffer.java (working copy)
> @@ -125,11 +125,11 @@
> }
> protected boolean isEndOfStream() {
> - return this.shutdown || (!hasData() && this.endOfStream);
> + return !hasData() && (this.shutdown || this.endOfStream);
> }
> public int read() throws IOException {
> - if (this.shutdown) {
> + if (this.isEndOfStream()) {
> return -1;
> }
> synchronized (this.mutex) {
> @@ -144,7 +144,7 @@
> }
> public int read(final byte[] b, int off, int len) throws IOException {
> - if (this.shutdown) {
> + if (this.isEndOfStream()) {
> return -1;
> }
> if (b == null) {
> @@ -168,7 +168,7 @@
> }
> public int read(final byte[] b) throws IOException {
> - if (this.shutdown) {
> + if (this.isEndOfStream()) {
> return -1;
> }
> if (b == null) {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org