2016-02-02 1:01 GMT+01:00 Mark Thomas <[email protected]>:
> > 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
