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