grizzly-sendfile update

[Igor Minar]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Hi all!


Seems that grizzly-http-webserver have some sort of issue in suspend/
resume request.

In the past i have already noticed this kind of issue, and seems that  
are related to http/1.0.

What i can say to give to you more information is that
1) suspend/resume WORK with modern browser using a "direct" access to  
website
2) suspend/resumw DOESN'T work if use DIRECTLY with flash on MACOSX  
(seems that  flash 8 for macosx implement an hold http stuff, it  
doesn't even parse cookie)
3) suspend/resume DOESN'T work if use a modern browser passing through  
a reverse proxy.

Reverse proxy wipe out some of the header (including keepalive,  
compression and things like that)


In the past, i have used GWS with ASYNCH adapter to "mime" suspend/
resume stuff, when i try to migrate to suspend/resume i have found  
some error in the past (ie http1.0 problem) and i choose to wait a bit  
longer :)

I have try now, but without success :(


The code is pretty simple, but if required i can write a test for you :)


best regards!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Oleksiy Stashok]

Hi Rama,

please write a test for us :)))

Thanks.

WBR,
Alexey.

On Sep 16, 2009, at 11:26 , rama wrote:

> Hi all!
>
>
> Seems that grizzly-http-webserver have some sort of issue in suspend/
> resume request.
>
> In the past i have already noticed this kind of issue, and seems  
> that are related to http/1.0.
>
> What i can say to give to you more information is that
> 1) suspend/resume WORK with modern browser using a "direct" access  
> to website
> 2) suspend/resumw DOESN'T work if use DIRECTLY with flash on MACOSX  
> (seems that  flash 8 for macosx implement an hold http stuff, it  
> doesn't even parse cookie)
> 3) suspend/resume DOESN'T work if use a modern browser passing  
> through a reverse proxy.
>
> Reverse proxy wipe out some of the header (including keepalive,  
> compression and things like that)
>
>
> In the past, i have used GWS with ASYNCH adapter to "mime" suspend/
> resume stuff, when i try to migrate to suspend/resume i have found  
> some error in the past (ie http1.0 problem) and i choose to wait a  
> bit longer :)
>
> I have try now, but without success :(
>
>
> The code is pretty simple, but if required i can write a test for  
> you :)
>
>
> best regards!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

> Hi Rama,
>
> please write a test for us :)))
>
> Thanks.
>
> WBR,
> Alexey.


Here we go :)

the test is quite bad wrote, i know :) probably i have even entered  
some non threadsafe piece
or some excessive locking who know :D

In any case i think that this will give to you an idea of what i do on  
my code. And also, i was able
to reproduce this error, using NGNX (or what-the-hell is the name of  
this webserver) as a reverseproxy (not provided by me, but
by the society that we use as a reverseproxy ddos protection)

So, a brief explain of that. (the part on parenthesis are the 'real  
usage' expalation)

When a request (to a special url that i call /push) the request is  
parsed in a different way.
(the session is created from cookie, check if the user is logged,  
check if htere are messages for that user, and if not..)
the request will be stopped, and after X second (or when someone add a  
messages for that user -not in the test case-) the
request is resumed.

This case is quite simplified, the usage case use and Executor to  
resume the request, to avoid blocking. Also the real case, is  
threadsafe :) (haven't checked this one sorry)


In any case, i have noticed that sometimes the request isn't resumed  
properly, or at least the data isnt' received when i pass through the  
revproxy.
I have also ckecked it with a "stupid" request (ie open socket, wrote  
GET / HTTP/1.0 and wait for response) and some times i get an error  
(but nothing on
grizzly console)

Hope that this help!


---------------
import java.io.IOException;
import java.util.ArrayList;
import java.util.Vector;
import com.sun.grizzly.http.embed.GrizzlyWebServer;
import com.sun.grizzly.tcp.CompletionHandler;
import com.sun.grizzly.tcp.http11.GrizzlyAdapter;
import com.sun.grizzly.tcp.http11.GrizzlyRequest;
import com.sun.grizzly.tcp.http11.GrizzlyResponse;
import com.sun.tools.javac.tree.Tree.Synchronized;

public class Main {

       
        public static void main(String[] args) throws Exception {
                new Main();
        }
       
        Main() {
                final pusher p = new pusher();
                GrizzlyWebServer ws = new GrizzlyWebServer(8080,"",false);
                ws.getSelectorThread().setCompression("on");
                ws.addGrizzlyAdapter(new GrizzlyAdapter() {
                        public void service(final GrizzlyRequest req, final GrizzlyResponse  
res) {
                                        if (!res.isSuspended()) {
                                                //request isn't suspended, suspend it, and put it somewhere
                                                //for a later resume :)
                                                res.suspend(Long.MAX_VALUE, this, new  
CompletionHandler<GrizzlyAdapter>() {

                                                        public void cancelled(GrizzlyAdapter attachment) {
                                                                        throw new Error("?!?");
                                                        }

                                                        public void resumed(GrizzlyAdapter attachment) {
                                                                  attachment.service(req,res);
                                      try {
                                                                        attachment.afterService(req,res);
                                                                  } catch (Exception e) {
                                                                        e.printStackTrace();
                                                                  }
                                                        }
                                                });
                                                p.add(res);
                                                System.out.println("SUSPEND");
                                                return;
                                               
                                        }
                                        //if i am here, request was suspended, then resumed, and we are  
able to write
                                        //something out
                                        System.out.println("OUT");
                                        try {
                                                res.getWriter().print("YEY");
                                        } catch (Exception e){
                                                e.printStackTrace();
                                        }
                        }
                },new String[]{});
                try {
                        ws.start();
                } catch (IOException e) {
               
                        e.printStackTrace();
                }
        }

       
        class pushOBJ {
                GrizzlyResponse res;
                int timeout;
                public pushOBJ(GrizzlyResponse r, int i) {
                        this.timeout = i;
                        this.res = r;
                }
               
        }
        class pusher extends Thread {
                 private Vector<pushOBJ> LIST= new Vector<pushOBJ>();
                 pusher() {
                         start();
                 }
               
                 public void add(GrizzlyResponse r) {
                         synchronized (LIST) {
                                 LIST.add(new pushOBJ(r,10));
                         }
                 }
                 public void run() {
                         while (true) {
                               
                                 synchronized (LIST) {
                                         for (int i = 0;i<LIST.size();i++) {
                                               
                                                 pushOBJ tmp = LIST.get(i);
                                               
                                                 System.out.println("CHECK "+tmp.timeout);
                                                 tmp.timeout--;
                                                 if (tmp.timeout == 0) {
                                                         //ersume request, remove this from list
                                                         LIST.remove(i);
                                                         i--; //dirty :D
                                                         tmp.res.resume();
                                                         System.out.println("RESUME!");
                                                 }
                                                 try {
                                                        LIST.wait(1000);
                                                } catch (InterruptedException e) {
                                                        // TODO Auto-generated catch block
                                                        e.printStackTrace();
                                                }
                                               
                                         }
                                 }
                         }
                 }
        }
}


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

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 :-)

>
> 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.

>
>
> 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.


>
> 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.

A+

--Jeanfrancois



>
> cheers,
> Igor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Igor Minar]

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@...
For additional commands, e-mail: dev-help@...

[Igor Minar]

Hi Jeanfrancois,

Were you able to reproduce the bugs I found?

/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@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

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@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Oleksiy Stashok]

Hi Rama,

sorry, just got some time to take a look at your sample.

IMHO the most suspicious part here is following:

                         public void resumed(GrizzlyAdapter  
attachment) {
                             attachment.service(req, res);
                             try {
                                 attachment.afterService(req, res);
                             } catch (Exception e) {
                                 e.printStackTrace();
                             }
                         }

Not sure it's good idea to call service and afterService from your code.
I'd rather suggest something like that:

                         public void resumed(GrizzlyAdapter  
attachment) {
                             //if i am here, request was suspended,  
then resumed, and we are able to write
                             //something out
                             System.out.println("OUT");
                             try {
                                 res.getWriter().print("YEY");
                             } catch (Exception e) {
                                 e.printStackTrace();
                             }
//
//                            attachment.service(req, res);
//                            try {
//                                attachment.afterService(req, res);
//                            } catch (Exception e) {
//                                e.printStackTrace();
//                            }
                         }


Please let me know if your app still doesn't work.

WBR,
Alexey.


On Sep 16, 2009, at 21:47 , rama wrote:

>
>> Hi Rama,
>>
>> please write a test for us :)))
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>
>
> Here we go :)
>
> the test is quite bad wrote, i know :) probably i have even entered  
> some non threadsafe piece
> or some excessive locking who know :D
>
> In any case i think that this will give to you an idea of what i do  
> on my code. And also, i was able
> to reproduce this error, using NGNX (or what-the-hell is the name of  
> this webserver) as a reverseproxy (not provided by me, but
> by the society that we use as a reverseproxy ddos protection)
>
> So, a brief explain of that. (the part on parenthesis are the 'real  
> usage' expalation)
>
> When a request (to a special url that i call /push) the request is  
> parsed in a different way.
> (the session is created from cookie, check if the user is logged,  
> check if htere are messages for that user, and if not..)
> the request will be stopped, and after X second (or when someone add  
> a messages for that user -not in the test case-) the
> request is resumed.
>
> This case is quite simplified, the usage case use and Executor to  
> resume the request, to avoid blocking. Also the real case, is  
> threadsafe :) (haven't checked this one sorry)
>
>
> In any case, i have noticed that sometimes the request isn't resumed  
> properly, or at least the data isnt' received when i pass through  
> the revproxy.
> I have also ckecked it with a "stupid" request (ie open socket,  
> wrote GET / HTTP/1.0 and wait for response) and some times i get an  
> error (but nothing on
> grizzly console)
>
> Hope that this help!
>
>
> ---------------
> import java.io.IOException;
> import java.util.ArrayList;
> import java.util.Vector;
> import com.sun.grizzly.http.embed.GrizzlyWebServer;
> import com.sun.grizzly.tcp.CompletionHandler;
> import com.sun.grizzly.tcp.http11.GrizzlyAdapter;
> import com.sun.grizzly.tcp.http11.GrizzlyRequest;
> import com.sun.grizzly.tcp.http11.GrizzlyResponse;
> import com.sun.tools.javac.tree.Tree.Synchronized;
>
> public class Main {
>
>
> public static void main(String[] args) throws Exception {
> new Main();
> }
>
> Main() {
> final pusher p = new pusher();
> GrizzlyWebServer ws = new GrizzlyWebServer(8080,"",false);
> ws.getSelectorThread().setCompression("on");
> ws.addGrizzlyAdapter(new GrizzlyAdapter() {
> public void service(final GrizzlyRequest req, final  
> GrizzlyResponse res) {
> if (!res.isSuspended()) {
> //request isn't suspended, suspend it, and put it somewhere
> //for a later resume :)
> res.suspend(Long.MAX_VALUE, this, new  
> CompletionHandler<GrizzlyAdapter>() {
>
> public void cancelled(GrizzlyAdapter attachment) {
> throw new Error("?!?");
> }
>
> public void resumed(GrizzlyAdapter attachment) {
>  attachment.service(req,res);
>                              try {
> attachment.afterService(req,res);
>  } catch (Exception e) {
> e.printStackTrace();
>  }
> }
> });
> p.add(res);
> System.out.println("SUSPEND");
> return;
>
> }
> //if i am here, request was suspended, then resumed, and we are  
> able to write
> //something out
> System.out.println("OUT");
> try {
> res.getWriter().print("YEY");
> } catch (Exception e){
> e.printStackTrace();
> }
> }
> },new String[]{});
> try {
> ws.start();
> } catch (IOException e) {
>
> e.printStackTrace();
> }
> }
>
>
> class pushOBJ {
> GrizzlyResponse res;
> int timeout;
> public pushOBJ(GrizzlyResponse r, int i) {
> this.timeout = i;
> this.res = r;
> }
>
> }
> class pusher extends Thread {
> private Vector<pushOBJ> LIST= new Vector<pushOBJ>();
> pusher() {
> start();
> }
>
> public void add(GrizzlyResponse r) {
> synchronized (LIST) {
> LIST.add(new pushOBJ(r,10));
> }
> }
> public void run() {
> while (true) {
>
> synchronized (LIST) {
> for (int i = 0;i<LIST.size();i++) {
>
> pushOBJ tmp = LIST.get(i);
>
> System.out.println("CHECK "+tmp.timeout);
> tmp.timeout--;
> if (tmp.timeout == 0) {
> //ersume request, remove this from list
> LIST.remove(i);
> i--; //dirty :D
> tmp.res.resume();
> System.out.println("RESUME!");
> }
> try {
> LIST.wait(1000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> }
> }
> }
> }
> }
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Igor Minar]

Hi there,

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 :-/

I fixed this as https://grizzly.dev.java.net/issues/show_bug.cgi?id=748

version 1.0.31 doesn't exist in the issue tracker yet, can you please  
create it and reassign the ticket appropriately please?

have you had any chance to look at the other bugs?

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@...
For additional commands, e-mail: dev-help@...

[Oleksiy Stashok]

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@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

Salut,

Igor Minar wrote:

> Hi there,
>
> 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 :-/
>
> I fixed this as https://grizzly.dev.java.net/issues/show_bug.cgi?id=748
>
> version 1.0.31 doesn't exist in the issue tracker yet, can you please
> create it and reassign the ticket appropriately please?
>
> have you had any chance to look at the other bugs?

I think I've just fixed the

>>>>>   final ProcessorTask task = asyncExecutor.getProcessorTask();
>>>>>   task.getSelectionKey().attach(SelectionKeyAttachment.DEREGISTERED);
>>>>>       task.getSelectionKey().cancel();

Try it and let me know.

Apology for the unbelievable long delay...

-- Jeanfrancois

>
> 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@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Igor Minar]

On Oct 8, 2009, at 7:59 AM, Jeanfrancois Arcand wrote:

> I think I've just fixed the
>
>>>>>>  final ProcessorTask task = asyncExecutor.getProcessorTask();
>>>>>>  
>>>>>> task
>>>>>> .getSelectionKey().attach(SelectionKeyAttachment.DEREGISTERED);
>>>>>>      task.getSelectionKey().cancel();
>
> Try it and let me know.
>
> Apology for the unbelievable long delay...

No, it still doesn't work. I get the same exceptions:

INFO: Starting Grizzly Framework 1.9.19-SNAPSHOT - Fri Oct 09 19:20:59  
PDT 2009

Exception in thread "GrizzlySendfileWorker-1"  
java.nio.channels.IllegalBlockingModeException
        at  
java
.nio
.channels
.spi
.AbstractSelectableChannel
.configureBlocking(AbstractSelectableChannel.java:257)
        at com.igorminar.grizzlysendfile.SendfileTask
$DefaultSendfileTask.run(SendfileTask.java:131)              <<<<  
socketChannel.configureBlocking(true);
        at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)

Oct 9, 2009 7:25:16 PM com.sun.grizzly.http.SelectorThread$3 onException
SEVERE: Exception during controller processing
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:
466)
        at  
com.sun.grizzly.TCPSelectorHandler.preSelect(TCPSelectorHandler.java:
397)
        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)

you can just run grizzly-sendfile-server to verify if a fix works:

$ java -jar target/grizzly-sendfile-server-0.3.2-SNAPSHOT-jar-with-
dependencies.jar -a  
com.igorminar.grizzlysendfile.algorithm.EqualBlockingAlgorithm ~/tmp/
test-files/
$ wget localhost:8080/some-existing-file


/i


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Igor Minar]

Hi guys,

did anyone have chance to look at the IllegalBlockingModeException  
issue?

thanks,
Igor


On Oct 9, 2009, at 7:38 PM, Igor Minar wrote:

>
> On Oct 8, 2009, at 7:59 AM, Jeanfrancois Arcand wrote:
>
>> I think I've just fixed the
>>
>>>>>>> final ProcessorTask task = asyncExecutor.getProcessorTask();
>>>>>>> task
>>>>>>> .getSelectionKey().attach(SelectionKeyAttachment.DEREGISTERED);
>>>>>>>     task.getSelectionKey().cancel();
>>
>> Try it and let me know.
>>
>> Apology for the unbelievable long delay...
>
>
> No, it still doesn't work. I get the same exceptions:
>
> INFO: Starting Grizzly Framework 1.9.19-SNAPSHOT - Fri Oct 09  
> 19:20:59 PDT 2009
>
> Exception in thread "GrizzlySendfileWorker-1"  
> java.nio.channels.IllegalBlockingModeException
> at  
> java
> .nio
> .channels
> .spi
> .AbstractSelectableChannel
> .configureBlocking(AbstractSelectableChannel.java:257)
> at com.igorminar.grizzlysendfile.SendfileTask
> $DefaultSendfileTask.run(SendfileTask.java:131)              <<<<  
> socketChannel.configureBlocking(true);
> at java.util.concurrent.ThreadPoolExecutor
> $Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor
> $Worker.run(ThreadPoolExecutor.java:908)
>
> Oct 9, 2009 7:25:16 PM com.sun.grizzly.http.SelectorThread$3  
> onException
> SEVERE: Exception during controller processing
> 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:
> 466)
> at  
> com.sun.grizzly.TCPSelectorHandler.preSelect(TCPSelectorHandler.java:
> 397)
> 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)
>
> you can just run grizzly-sendfile-server to verify if a fix works:
>
> $ java -jar target/grizzly-sendfile-server-0.3.2-SNAPSHOT-jar-with-
> dependencies.jar -a  
> com.igorminar.grizzlysendfile.algorithm.EqualBlockingAlgorithm ~/tmp/
> test-files/
> $ wget localhost:8080/some-existing-file
>
>
> /i
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

Salut,

Igor Minar wrote:
> Hi guys,
>
> did anyone have chance to look at the IllegalBlockingModeException issue?

Unfortunately not. We are still in a V3 mode right now, doing everything
we can to get out of it :-)

A+

-- Jeanfrancois

>
> thanks,
> Igor
>
>
> On Oct 9, 2009, at 7:38 PM, Igor Minar wrote:
>
>>
>> On Oct 8, 2009, at 7:59 AM, Jeanfrancois Arcand wrote:
>>
>>> I think I've just fixed the
>>>
>>>>>>>> final ProcessorTask task = asyncExecutor.getProcessorTask();
>>>>>>>> task.getSelectionKey().attach(SelectionKeyAttachment.DEREGISTERED);
>>>>>>>>     task.getSelectionKey().cancel();
>>>
>>> Try it and let me know.
>>>
>>> Apology for the unbelievable long delay...
>>
>>
>> No, it still doesn't work. I get the same exceptions:
>>
>> INFO: Starting Grizzly Framework 1.9.19-SNAPSHOT - Fri Oct 09 19:20:59
>> PDT 2009
>>
>> Exception in thread "GrizzlySendfileWorker-1"
>> java.nio.channels.IllegalBlockingModeException
>>     at
>> java.nio.channels.spi.AbstractSelectableChannel.configureBlocking(AbstractSelectableChannel.java:257)
>>
>>     at
>> com.igorminar.grizzlysendfile.SendfileTask$DefaultSendfileTask.run(SendfileTask.java:131)              
>> <<<< socketChannel.configureBlocking(true);
>>     at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>
>>     at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>
>>
>> Oct 9, 2009 7:25:16 PM com.sun.grizzly.http.SelectorThread$3 onException
>> SEVERE: Exception during controller processing
>> 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:466)
>>
>>     at
>> com.sun.grizzly.TCPSelectorHandler.preSelect(TCPSelectorHandler.java:397)
>>     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)
>>
>> you can just run grizzly-sendfile-server to verify if a fix works:
>>
>> $ java -jar
>> target/grizzly-sendfile-server-0.3.2-SNAPSHOT-jar-with-dependencies.jar
>> -a com.igorminar.grizzlysendfile.algorithm.EqualBlockingAlgorithm
>> ~/tmp/test-files/
>> $ wget localhost:8080/some-existing-file
>>
>>
>> /i
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...