On 02/02/2016 09:29, Rémy Maucherat wrote:
> 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.
But acceptLargeFragments can change via a call to
SSLSessionImpl.expandBufferSizes().
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
