Salut,
Igor Minar wrote:
> Hi Jeanfrancois,
>
> Were you able to reproduce the bugs I found?
Apology. I'm running out of time those days. Will try to look it asap.
A+
-- Jeanfrancois
>
> /i
>
>
> On Sep 16, 2009, at 1:43 PM, Igor Minar wrote:
>
>>
>> On Sep 16, 2009, at 12:59 PM, Jeanfrancois Arcand wrote:
>>
>>> Salut,
>>>
>>> Igor Minar wrote:
>>>> 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
>>>
>>> This is great. BTW since you have commit privileges, you can backport
>>> the fix you need in 1.0.31 :-)
>>
>> sure, can you point me to the source code? I know that it was
>> originally in the glassfish repo and then it was moved to the grizzly
>> repo, but I can't find it there :-/
>>
>>
>>>
>>>
>>>> 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
>>>
>>> OK file an issue so we don't forget it.
>>
>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=736
>>
>>>
>>>
>>>
>>>> 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)
>>>>
>>>
>>> OK that one I don't get it. The code above looks good. So it's
>>> between 1.9.16 and 17 that we have re-introduced the regression.
>>> Looking at it.
>>
>>
>> thanks
>>
>>
>>>
>>>
>>>> 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.
>>>
>>> Great work! I would really like to make it work/merge and allow users
>>> of GlassFish v3 to use it.
>>
>>
>> Almost there! Once these issues are resolved, I'm going to do a round
>> of thorough load testing and then grizzly-sendfile will be ready for
>> the integration.
>>
>> /i
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>