On 8/8/11 8:47 AM, Gay David (Annecy) wrote:
>
> Hi Alexey,
>
> Yep, I think I got it. See my attached sample test case.
>
> It use Grizzly 2.1.2-SNAPSHOT checkout from yesterday.
>
> If you run it like that, it works.
>
> But if you modified the class UploadTask like that :
>
> //--- Constructor
> ----------------------------------------------------------
>
> public UploadTask( Request req, Response res ) throws
> FileNotFoundException
>
> {
>
> this.req = req;
>
> this.res = res;
>
> //this.channel = Channels.newChannel( new FileOutputStream(new
> File("toto-"+COUNT.getAndIncrement()+".data")) );
>
> this.channel = Channels.newChannel( new NullOutputStream() );
>
> this.error = null;
>
> // Get the non-blocking input stream from the Grizzly thread :
> IT WORKS
>
> *///this.is = req.getInputStream( false );*
>
> }
>
> //--- Runnable implementation
> ----------------------------------------------
>
> @Override
>
> public void run()
>
> {
>
> // Get the non-blocking input stream from the thread pool : IT
> DOES NOT WORKS !
>
> *this.is = req.getInputStream( false );*
>
> is.notifyAvailable( this, PREFERRED_SIZE );
>
> }
>
> Then, it doesn't work. As I don't know why, I think the only
> difference is that the getInputStream() call is made in the Grizzly
> thread in the constructor, while the the same call is made from my
> executor thread poll. It's not obvious for me what's happen in the
> Grizzly code.
>
> So my questions :
>
> ·Is my theory correct ?
>
Yes. In the working case, the HttpServerFilter is properly configured
for async operations when AsyncHandler.service(). This is true because,
like you said, getInputStream() was called within the constructor of
UploadTask, so the HttpServerFilter had the correct state. When you
called getInputStream() within the run() method, AsyncHandler.service()
had already exited. Since the async state wasn't present at that time,
the HttpServerFilter will only operate in blocking mode.
> ·Is it a mistake to call the getInputStream() from thread other than
> the Grizzly ones ?
>
I think the rule of thumb is that getInputStream() must be called before
exiting the service() method of your handler.
> ·Or, is it a limitation/bug of the current version ? If so, do you
> want me to open an issue ?
>
It's a limitation (albeit a minor one). I think we should document this
and move on.
> Thanks
>
> David
>
> *De :*Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
> *Envoyé :* lundi 8 août 2011 13:45
> *À :* users_at_grizzly.java.net
> *Objet :* Re: From Grizzly 1.9.x to 2.x
>
> Hi David,
>
> the issue is probably in the ReadHander registration code, not in
> actual ReadHandler.
> Can you pls. share more code, may be working (or better say
> non-working) sample?
>
> Thanks.
>
> WBR,
> Alexey.
>
>