Provide support for sending Content.Source via sendfile / FileChannel.transferTo

[kohlschuetter]

Jetty version(s)
12.x

Enhancement Description
Currently, it appears that all data provided via Content.Source or Path resource is transferred to the client socked by copying data in userspace (via ByteBuffers).

In many cases, it may be possible to leverage sendfile(2) / FileChannel.transferTo to serve content directly from kernel buffers. This may greatly improve throughput and also reduce CPU usage when transferring lots of data.

We could do the following:

1. Add an asWritableByteChannel method to Content.Sink, which may or may not return an optimized WritableByteChannel, depending on filters, etc.
2. Give Content.Source the ability to write to a Content.Sink directly (without forcibly using ContentCopier). Suitable Content.Source implementations may call Content.Sink#asWritableByteChannel and use FileChannel#transferTo(long,long,WritableByteChannel) with the corresponding data.
3. Optimize the Content.Sink implementation in ServletChannel to return a direct-socket WritableByteChannel whenever possible.
4. Improve IOResources.PathToSinkCopier as well.

[sbordet]

Can you detail the cases? Because they are not very many, possibly just one: HTTP/1.1 with known Content-Length.
For example, cannot be done for HTTP/2, nor for HTTP/3, nor HTTP/1.1 chunked.

When Jetty serves files, it can efficiently use file mapping, which should be equivalent.

Is the use case about applications serving files, that cannot be done by ResourceHandler or DefaultServlet?

[kohlschuetter]

In principle, sendfile(2)/FileChannel.transferTo can be used for all sorts of file-backed streams since an offset and count can be specified, including chunked encoding (sending 1 chunk = 1 transferTo)

So, whenever you're serving data from the filesystem, that approach lets us skip in-process buffering, which however — I believe — all current handlers in jetty do, including ResourceHandler (it uses Content.copy under the hood).

In my concrete case, I'm interested in serving content to HTTP/1.1 and WebDAV clients (I have a working WebDAV integration on top of embedded Jetty). The data would either be provided by files in the file system or (which is possible in Linux) transferred from another FileDescriptor via pipe (using splice or vmsplice), which can then be sent over the HTTP connection.

Moreover, there could be further performance improvements by combining this approach with Kernel TLS (kTLS), which was motivated by the need to support sendfile over TLS.

[sbordet]

I'll look into kTLS, thanks for sharing that.

In your concrete case, do I understand right that you can already serve the files with ResourceHandler -- I'm assuming it can do file mapping, but I'll double-check.

[kohlschuetter]

I can use ResourceHandler to serve files from the FileSystem. I can make it work (via read/write) to support the pipe use case, but performance is impacted.

[sbordet]

I pushed just a sketch about this to branch fix/jetty-12.1.x/13392/response-content-source.

Main Design

Applications do this in a Handler:

response.setContentSource(Content.Source.from(path));
response.write(true, null, callback);

Response.contentSource is then forwarded to MetaData.Response.contentSource.

Now that the Content.Source is in the MetaData.Response, every protocol version can generate content out of it.

Add method Content.Source.writeTo(Sink, int length, Callback).

With this method, generators can first generate the headers as usual, and then do the following:

metaDataResponse.getContentSource().writeTo(endPoint, length, callback);

This may be generically implemented by read()/demand()+write().
But for a ContentSource backed by a FileChannel and a Sink backed by a SocketChannel, then it may be implemented with FileChannel.transferTo().

Details

1. Response.setContentSource() may be wrapped, so e.g. CompressionResponse will wrap the Content.Source set by the application, then forwards it to the wrapped response.
   The innermost response object will have the compressed Content.Source, but won't be able to call FileChannel.transferTo() (since the compressed ContentSource is not backed by a FileChannel).
2. With TLS, we won't be able to call FileChannel.transferTo() because the EndPoint is not backed by a SocketChannel.
   I read about Kernel TLS, but AFAIK this is not available in Java (i.e. it is not possible to pass the SocketOption necessary to enable it) -- despite a LinkedIn entry that I don't think is accurate (and feels very much like an AI hallucination). I checked the OpenJDK source code and there is no trace of what mentioned in LinkedIn.
3. For HTTP/1.1 Chunked TE, when applications want to explicitly have multiple chunks, it would be possible to do this:

response.setContentSource(Content.Source.from(path, 0, length1));
response.write(false, null, callback);
response.setContentSource(Content.Source.from(path, length1, length2));
response.write(true, null, callback);

4. HTTP/2 must be able to constrain the length of the chunk written via FileChannel.transferTo(), so that's why Content.Source.writeTo(endPoint, length, callback) has an int length parameter.
   This is necessary for maxFrameSize and flow control.
5. A Content.Source that implements writeTo() must mutually exclude read()/demand() when writeTo() is called, and viceversa.
6. Have not analyzed the impact on ResourceService and the HttpContent.Factory machinery.

Discussion

@lorban I remember that one day we clearly captured why it was not a good idea to have multiple write() method in Response or Sink. I vaguely remember it had to do with wrapping.
We need to refresh that conversation because Response.write(boolean last, Content.Source s, Callback c) feels more natural.

In my branch above I was actually able to arrive to FileChannel.transferTo(); obviously only works for clear-text, but perhaps it is common enough to have Jetty behind TLS offloading, and compression can be done with pre-compressed files.

I like Response.write(boolean last, Content.Source s, Callback c) better, but I'm not sure if we can go that direction.
Response.setContentSource() offers a side for misuse, which we would need to fix by throwing UnsupportedOperationException or similar.
For example, Response.setContentSource() followed by response.write(true, someByteBuffer, callback): the fact that the Content.Source is written is not explicit; should someByteBuffer be written before or after the Content.Source, etc.

@gregw thoughts?

[sbordet]

I can see 4 API options:

1. Response.setContentSource() + response.write() -- the Content.Source is set aside, and the application initiates a write() to generate and write the response headers, and later the implementation will retrieve the Content.Source to write the content, possibly via transferTo().
2. response.write(boolean, Content.Source, Callback) -- has the problem of being an additional "write" method, so wrapping is more complicated, and every wrapper has to do the same work twice.
3. static void Response.write(Response, boolean,Content.Source, Callback) -- almost as nice as 2., but allows the implementation details to be hidden; the implementation details could be similar to 1., but not exposed in public APIs.
4. Content.copy(Source, Sink, Callback) -- has the problem that it is generic (i.e. we do not know that the Sink is-a Response); while now it works because we always call sink.write(), if we bypass it by calling transferTo() then we won't generate the response headers; therefore, it would need to perform an initial write that is only necessary if the Sink is-a Response, which does not seem right.

I think 3. is the best option.

[lorban]

I also have a preference for option 3, but we do have to do something about Content.copy() too.

Since the goal is to improve the performance of serving static data, we would at least need to modify IOResources so that it calls Response.write(): ResourceService relies on IOResources to serve static content and the latter heavily relies on Content.copy() to transfer resources to sinks.