On 24/10/2014 00:40, Konstantin Kolinko wrote: > 2014-10-24 0:01 GMT+04:00 Mark Thomas <ma...@apache.org>: >> On 17/10/2014 17:17, Konstantin Kolinko wrote: >>> 2014-10-13 23:27 GMT+04:00 <ma...@apache.org>: >>>> Author: markt >>>> Date: Mon Oct 13 19:27:37 2014 >>>> New Revision: 1631520 >>>> >>>> URL: http://svn.apache.org/r1631520 >>>> Log: >>>> Cache the Encoder instances used to convert Strings to byte arrays in the >>>> Connectors (e.g. when writing HTTP headers) to improve throughput. >>> >>> In this implementation I think the cache only plays when the same >>> MessageBytes instance is re-used in subsequent requests. >> >> Correct. This happens often enough (especially for the HTTP headers) >> that there was a measurable performance improvement. That doesn't mean >> that there isn't scope for further improvement. >> >>> I think an alternative implementation using a thread-local cache will >>> allow to reuse encoders between different MessageByte instances in the >>> same request and will require less memory. >> >> I don't like the idea of a ThreadLocal cache as it has the potential to >> expose data from one request to another. In shared hosting that could be >> problematic. >> >> A global cache of encoders (keyed on charset) that can be used by >> MessageBytes (and potentially elsewhere) and then returned (i.e. all >> internal code so we can be sure there is no leakage across requests) >> might work. > > > An encoder is configured up to the task (with onMalformedInput() > etc.). A generic cache is...
There was an unstated assumption that all the places using the cache would be happy with the same Encoder configuration. > I think I found it: > java.nio.charset.Charset.encode(String) > java.nio.charset.Charset.encode(CharBuffer) > > The latter method uses thread-local cache (in Java 7). > > Some feeling of deja-vu is because of discussion of decoders that we > had 3 years ago. See code in ByteChunk.toStringInternal() as a result > of that. I don't remember that discussion at all. I'll re-read that discussion, take a look at the implementation and see what the performance impact of switching to that approach is. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
