users@grizzly.java.net

RE: From Grizzly 1.9.x to 2.x

From: Gay David (Annecy) <"Gay>
Date: Tue, 9 Aug 2011 12:00:34 +0000

Hi,

Thanks for your explanations. It's clear now.
As you suggest, I open a Improvement issue on the Grizzly's JIRA here : http://java.net/jira/browse/GRIZZLY-1056

Just one comment : I set the priority to "Major". You may be not agree on that, but it is for my use case.
I may be the only one that use Grizzly like that, so I would understand if you decide to change the priority.

I can explain briefly how I works with Grizzly :

I have a main handler that serve all request and do unconditionally :

- Suspend the response

- Given the url, find a "RequestProcessor" and delegate the processing to a thread pool

It was made like that because it allow us to serve many request in parallel without increasing the Grizzly worker thread (that consume lot of memory in Grizzly 1.9.x)

As the request processor is a interface, the main handler don't have any knowledge about what it want to do.
It was made to be generic and pluggable for future needs.

We have also put some service facilities for RequestProcessor implementor that allow them to download a file with a simple line of code, for example :
DonwloadManager.download( request, response, inputstream ) -> it serve the resource input stream to the client in an async manner.
And this is inside the Download/Upload Manager I would like to use the new async read/write of Grizzly 2.
From a functional point of view, it fit perfectly well.
But as it already suspend and run inside my request processor thread, it not possible.

So, sorry to bother you with all my stuff, my goal was just to try to argument why I put the priority to "Major"


Thanks all for your help
Regards
David


De : Ryan Lubke [mailto:ryan.lubke_at_oracle.com]
Envoyé : lundi 8 août 2011 21:25
À : users_at_grizzly.java.net
Objet : Re: From Grizzly 1.9.x to 2.x

On 8/8/11 11:57 AM, Ryan Lubke wrote:
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.

After further discussion, we've documented the limitation, but we'll try to resolve this in the next release.
Please do log an issue.

Thanks,
-rl






Thanks
David

De : Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
Envoyé : lundi 8 août 2011 13:45
À : users_at_grizzly.java.net<mailto: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.