Bug 45154 - Support sendfile with NIO and SSL
Summary: Support sendfile with NIO and SSL
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.16
Hardware: PC All
: P2 enhancement (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-06 16:16 UTC by M McClain
Modified: 2009-01-14 16:21 UTC (History)
0 users



Attachments
Patch for Tomcat 6.0.16 (4.41 KB, patch)
2008-06-06 16:16 UTC, M McClain
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description M McClain 2008-06-06 16:16:23 UTC
Created attachment 22092 [details]
Patch for Tomcat 6.0.16

We upgraded to Tomcat 6.0 to take advantage of NIO.
We have a couple servlets which use SSL for secure download
of very large files and needed it to scale.

Disappointed that the sendfile functionality didn't work
with NIO when using SSL, I dug in until I got something to
work.

I'm attaching a patch.

The part that I'm least comfortable was the change to SecureNioChannel
because I didn't know why the check was there to begin with.
Comment 1 Filip Hanik 2008-08-21 16:15:10 UTC
Hi Mr McClain,
the benefit of sendfile is that you can transfer data from one channel to another without reading the data into the java heap.
this is not possible with SSL, since you have to do the encryption in memory, so the effort is wasted, and doing it this way, you will be wasting poller CPU cycles on SSL encryption, potentially slowing down the system's reaction time to IO events.

so the transferTo is supposed to read from the one buffer to another without reading data into memory (the java heap), this effort doesn't work with NIO ssl.

what would have to be done here, is that we moved the send file to a separate thread, but it still wouldn't be a true send file.

Filip
Comment 2 M McClain 2008-08-21 18:05:15 UTC
I understand what you're saying about doing too much
in the poller thread.

I was trying to accomplish handling hundreds of clients
that could simultaneously download a 200 MB file without
tying up a separate thread per client on blocking I/O.

And I hoped the NIO mechanism would additionally use
less RAM.

Unfortunately, from the servlet layer we only have
access to an OutputStream.
Comment 3 Mark Thomas 2008-11-08 18:01:01 UTC
Changing this to an enhancement since there isn't anything broken here. Patches along the lines of Filip's suggestion welcome.
Comment 4 Filip Hanik 2008-11-26 12:35:27 UTC
Proposal for inclusion and performance improvement is added here
  http://svn.apache.org/viewvc?rev=720724&view=rev
  http://svn.apache.org/viewvc?rev=720728&view=rev 
The important thing is to never call a blocking method within the poller

Proposal for inclusion in 6.0.x branch has been created.
Comment 5 Filip Hanik 2009-01-14 16:21:16 UTC
This has been fixed in 6.0.x and will be included in 6.0.19 onwards.