2016-09-14 14:37 GMT+03:00 Mark Thomas <ma...@apache.org>:
> On 13/09/2016 19:07, Violeta Georgieva wrote:
> > 2016-08-30 15:35 GMT+03:00 Violeta Georgieva <miles...@gmail.com>:
> >> I introduced CoyoteOutputStream.write(ByteBuffer) it uses new methods
> >> with ByteBuffer instead of ByteChunk.
> >> Next step is to replace ByteChunk/CharChunk usage in CoyoteOutputStream
> >> with ByteBuffer/CharBuffer thus I will switch to the new methods and
> >> CoyoteOutputStream.write method will use them.
> > I would like to back port these changes to Tomcat 8.5 if you do not have
> > any concerns.
> I'm a little concerned about destabilising 8.5.x but the CI system looks
> to be doing a good job of catching problems.
In addition to the Tomcat test suite I executed many combinations of
and I do not experience any stability or performance problems with the new
> Generally, I like the direction this is heading in. Reducing copying
> should improve performance but the impact of that doesn't seem to be
> noticeable so far. I do wonder why. Time to add some performance testing
> to my TODO list I think.
Yes I reduced the copy operations, but there is still copy operation when
the socket write buffer is not empty.
> Currently, there are essentially two code paths for read and write.
> 1. Original. User facing API uses byte. byte retained all the way to
> the SocketWrapper where it is copied to ByteBuffer.
The byte is wrapped to a ByteBuffer in order to use the new API and when
possible copy is skipped.
org.apache.catalina.connector.OutputBuffer is working with ByteBuffer after
> 2. New. User facing API uses ByteBuffer. ByteBuffer retained all the way
> to to the SocketWrapper where it is used if possible or copied to
> another ByteBuffer if not.
> I haven't explored this at all so far, but my initial impression is that
> a lot of duplicated functionality could be removed if the original code
> path copied to a ByteBuffer earlier.
Yes my next step is to deprecate and remove the duplicated functionality as
it is not used as I mentioned above.
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org