Hi there,
I'd like to give you an update on the grizzly-sendfile progress. Due
to a combination of reasons I wasn't able to dedicate much time to the
project until recently, but the progress I made in the last few weeks
should offset the delay.
Some notable changes:
- http range support for all single range combination defined in the
HTTP1.1 spec (this means that partial/resumable downloads are now
fully supported)
- support for ssl transfers (YAY!)
- data source abstraction (a file on the filesystem is just one of
many supported data sources, the source of data can be local memory,
database, hadoop fs, memcached, you name it)
- new plugin hook that should make it trivial to add gzip compression
or other kind of data manipulation before the data is written to the
socket channel
- lots of refactoring to clean things up and optimize code execution
paths
- as the result of the refactoring, I'm now considering supporting
grizzly 1.0.x, 1.9.x and 2.0 all from the same grizzly-sendfile core
code base
that's about it for the good news, no is the time for some bad news :)
The last version of grizzly that worked well with grizzly-sendfile was
1.9.15, I tried using 1.9.16, 1.9.17, 1.9.18, 1.9.18a but no release
after 1.9.15 works well.
Here are issues I know about:
1) Under stress, grizzly starts spewing these exceptions after several
hundreds or thousands of requests:
Sep 15, 2009 3:42:22 PM com.sun.grizzly.SelectorHandlerRunner
handleSelectException
WARNING: Channel was unexpectedly closed
Sep 15, 2009 3:42:22 PM com.sun.grizzly.http.SelectorThread$3
onException
SEVERE: Exception during controller processing
java.nio.channels.ClosedChannelException
at
java
.nio
.channels
.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:
167)
at
com
.sun
.grizzly
.DefaultSelectionKeyHandler.register(DefaultSelectionKeyHandler.java:
162)
at
com
.sun
.grizzly
.TCPSelectorHandler.processPendingOperations(TCPSelectorHandler.java:
464)
at
com.sun.grizzly.TCPSelectorHandler.preSelect(TCPSelectorHandler.java:
395)
at
com
.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:
183)
at
com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:
130)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:637)
at java.lang.Thread.run(Thread.java:637)
this issue was introduced in 1.9.17 and is still present in 1.9.18a
2) an older issue that was reintroduced in 1.9.17 and is still present
in 1.9.18a -
https://grizzly.dev.java.net/issues/show_bug.cgi?id=548
it completely prevents grizzly-sendfile from supporting blocking IO,
so I had to revert the default to 100% non-blocking IO and get used to
the performance penalty.
Exception in thread "GrizzlySendfileWorker-0"
java.nio.channels.IllegalBlockingModeException
at
java
.nio
.channels
.spi
.AbstractSelectableChannel
.configureBlocking(AbstractSelectableChannel.java:257)
at com.igorminar.grizzlysendfile.SendfileTask
$DefaultSendfileTask.run(SendfileTask.java:131)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:637)
or occasionally:
Sep 15, 2009 9:23:26 AM com.sun.grizzly.SelectorHandlerRunner
handleSelectException
SEVERE: doSelect exception
java.nio.channels.IllegalBlockingModeException
at
java
.nio
.channels
.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:
172)
at
com
.sun
.grizzly
.DefaultSelectionKeyHandler.register(DefaultSelectionKeyHandler.java:
162)
at
com
.sun
.grizzly
.TCPSelectorHandler.processPendingOperations(TCPSelectorHandler.java:
464)
at
com.sun.grizzly.TCPSelectorHandler.preSelect(TCPSelectorHandler.java:
395)
at
com
.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:
183)
at
com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:
130)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:637)
relevant code:
//in an AsyncFilter
final ProcessorTask task = asyncExecutor.getProcessorTask();
task.getSelectionKey().attach(SelectionKeyAttachment.DEREGISTERED);
task.getSelectionKey().cancel();
//elsewhere later
selectionKey.cancel();
socketChannel.configureBlocking(true); //>>> Exception: at
com.igorminar.grizzlysendfile.SendfileTask
$DefaultSendfileTask.run(SendfileTask.java:131)
There might be more issues, but they are not visible due the issues
described above.
If you want to try grizzly-sendfile, you can just grab the latest jar
from
https://kenai.com/svn/grizzly-sendfile~maven/com/igorminar/
grizzly-sendfile/grizzly-sendfile-server/0.3.2-SNAPSHOT/grizzly-
sendfile-server-0.3.2-SNAPSHOT-jar-with-dependencies.jar
You can run the server as:
java -jar grizzly-sendfile-server-0.3.2-SNAPSHOT-jar-with-
dependencies.jar /path/to/some/files
If you want to test the bug #2:
java -jar grizzly-sendfile-server-0.3.2-SNAPSHOT-jar-with-
dependencies.jar -a
com.igorminar.grizzlysendfile.algorithm.EqualBlockingAlgorithm /path/
to/some/files
once these final issues are resolved, grizzly-sendfile code will be
ready to be used by grizzly.
cheers,
Igor