There was a circumstance where the framed input stream could hang if the

frame size was exactly the same size as the buffer and no future messages
came down the pipe to wake us up again. This probably would have had to
happen very early in the session as the buffer gets bigger and bigger to
accomodate the largest frame seen during the entire session and
asynchronous messages are coming in more frequently as well. Thus it's
extremely unlikely that this ever actually hung. In any case, we now log
that circumstance (and do the right thing) so we can see if the log
message turns up in future bug reports.


git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2693 542714f4-19e9-0310-aa3c-eee0fc999fb1
This commit is contained in:
Michael Bayne
2003-07-06 18:39:55 +00:00
parent 5c34de0283
commit 17b567ba18
@@ -1,5 +1,5 @@
//
// $Id: FramedInputStream.java,v 1.3 2002/12/10 19:33:22 mdb Exp $
// $Id: FramedInputStream.java,v 1.4 2003/07/06 18:39:55 mdb Exp $
package com.threerings.io;
@@ -96,6 +96,18 @@ public class FramedInputStream extends InputStream
// what we've got
if (_buffer.remaining() > 0) {
break;
} else if (_length == -1) {
// if we didn't already have our length, see if we now have
// enough data to obtain it
_length = decodeLength();
}
// additionally, if the buffer happened to be exactly as long
// as we needed, we need to break as well
if ((_length > 0) && (_have >= _length)) {
System.err.println("Phew, we would have been screwed in " +
"the previous release (" + _length + ").");
break;
}
// otherwise, we've filled up our buffer as a result of this
@@ -107,12 +119,6 @@ public class FramedInputStream extends InputStream
// don't let things grow without bounds
} while (_buffer.capacity() < MAX_BUFFER_CAPACITY);
// if we didn't already have our length, see if we now have enough
// data to obtain it
if (_length == -1) {
_length = decodeLength();
}
// finally check to see if there's a complete frame in the buffer
// and prepare to serve it up if there is
return checkForCompleteFrame();