tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: svn commit: r1727992 - in /tomcat/trunk: java/org/apache/tomcat/util/net/SecureNioChannel.java webapps/docs/changelog.xml
Date Tue, 02 Feb 2016 09:46:43 GMT
On 02/02/2016 09:29, Rémy Maucherat wrote:
> 2016-02-02 1:01 GMT+01:00 Mark Thomas <markt@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message