Re: svn commit: r1757813 - in /tomcat/trunk/java/org/apache/tomcat/util/net: AprEndpoint.java Nio2Endpoint.java NioEndpoint.java SocketWrapperBase.java

[Violeta Georgieva]

Hi Remy,

2016-08-26 15:06 GMT+03:00 Rémy Maucherat :
>
> 2016-08-26 12:23 GMT+02:00 :
>
> > Author: violetagg
> > Date: Fri Aug 26 10:23:15 2016
> > New Revision: 1757813
> >
> > URL: http://svn.apache.org/viewvc?rev=1757813=rev
> > Log:
> > Introduce a new method SocketWrapperBase.doWrite(boolean, ByteBuffer)
> >
> > Modified:
> > tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
> > tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
> > tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
> > tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapperBase.java
> >
> > I did examine adding some ByteBuffer write methods (as you can see in
the
> API), with gather writes in mind with NIO2 for HTTP/2, but:
> - Since the other write method also exists, if the main buffer isn't
empty,
> there will be corruption. Let's say that's not a problem: the user is
> supposed to know what it is doing and will have to flush :)
> - A single buffer is most likely more memory efficient.
> - I redid HTTP/2 with my async gather writes, minimizing contention more,
> and ... the performance was measurably worse than the regular code. So I
> gave up on it. Maybe reads will be more useful (no more blocking reads for
> HTTP/2 headers, this is not really supposed to happen of course, but still
> decent to have).
> - When using SSL, the single buffer system is *way* better since it can be
> a direct BB, which avoids a ton of allocation and buffer copies.
>
> So I doubt this is more useful than my own additions, but on the positive
> side, the changes are minimal.
>

This is just a preparation for the next commits.
I'm not going to remove the write methods with byte array for the moment
but introduce in parallel write method with ByteBuffer.
When implementing CoyoteOutputStream.write(ByteBuffer) I do not want to
make conversion to byte array but want to use ByteBuffer only.

Thanks,
Violeta

> Rémy

Re: svn commit: r1757813 - in /tomcat/trunk/java/org/apache/tomcat/util/net: AprEndpoint.java Nio2Endpoint.java NioEndpoint.java SocketWrapperBase.java

[Rémy Maucherat]

2016-08-26 12:23 GMT+02:00 :

> Author: violetagg
> Date: Fri Aug 26 10:23:15 2016
> New Revision: 1757813
>
> URL: http://svn.apache.org/viewvc?rev=1757813=rev
> Log:
> Introduce a new method SocketWrapperBase.doWrite(boolean, ByteBuffer)
>
> Modified:
> tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
> tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
> tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
> tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapperBase.java
>
> I did examine adding some ByteBuffer write methods (as you can see in the
API), with gather writes in mind with NIO2 for HTTP/2, but:
- Since the other write method also exists, if the main buffer isn't empty,
there will be corruption. Let's say that's not a problem: the user is
supposed to know what it is doing and will have to flush :)
- A single buffer is most likely more memory efficient.
- I redid HTTP/2 with my async gather writes, minimizing contention more,
and ... the performance was measurably worse than the regular code. So I
gave up on it. Maybe reads will be more useful (no more blocking reads for
HTTP/2 headers, this is not really supposed to happen of course, but still
decent to have).
- When using SSL, the single buffer system is *way* better since it can be
a direct BB, which avoids a ton of allocation and buffer copies.

So I doubt this is more useful than my own additions, but on the positive
side, the changes are minimal.

Rémy