2016-02-02 1:01 GMT+01:00 Mark Thomas <ma...@apache.org>: > > Well, the design is so wrong. > > I'm not a fan of the solution either but I couldn't see a better way to > resize the buffer. > > I thought about: > - custom exception - rejected since exceptions are slow and flow control > via exception is bad > - custom return value (-2, Integer.MIN_VALUE or similar) - rejected > because it is non-standard and would require changes up the call-stack > to handle it. > - increasing the default buffer size - rejected as the smaller buffer > is enough in nearly all cases > > Anything else I thought of required invasive API changes. A related > issue is the read(ByteBuffer) provides no way to expose the expanded > ByteBuffer to the caller but that method is part of the ByteChannel API. > > Suggestions welcome. >
Will think about that :) At some point I'll likely have to add another read buffer in SecureNio2Channel since I would like more flexibility ... > > > BTW, what is the > > getSession().getApplicationBufferSize() value here ? And that's with > > OpenSSL or JSSE ? > > Roughly 16k or 32k for JSSE with current Oracle Java 8 as far as I can > tell. Something, I didn't figure out what, was triggering a switch to > the larger buffer size after we had initialised the buffers. > > The OpenSSL implementation only ever uses 16k so it shouldn't hit this > code. > > IMO there's something wrong with the behavior since my JDK 8 source is (for JSSE): @Override public synchronized int getPacketBufferSize() { return acceptLargeFragments ? Record.maxLargeRecordSize : Record.maxRecordSize; } @Override public synchronized int getApplicationBufferSize() { return getPacketBufferSize() - Record.headerSize; } And the fields from Record are static (obviously) and final. The value returned thus shouldn't be able to change. Rémy