Hi Igor,
>>> 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 :-/
>
> I fixed this as https://grizzly.dev.java.net/issues/show_bug.cgi?
> id=748
great!!!
> version 1.0.31 doesn't exist in the issue tracker yet, can you
> please create it and reassign the ticket appropriately please?
done.
> have you had any chance to look at the other bugs?
As for Grizzly 2.0 - didn't have time for it. I'm 100% on GF issues
now :)
WBR,
Alexey.
>
> thanks,
> Igor
>
>>
>>
>>>
>>>
>>>> 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
>