users@jersey.java.net

Re: Possible bug in Grizzly <was> Re: Grizzly Container is completely wrong, if I read it correctly

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 05 Dec 2007 10:54:18 +0100

Jeanfrancois Arcand wrote:
>> I worked around the problem.
>>
>> Basically the sleep statement after the starting the thread with
>> 'selectorThread.startEndpoint()' was not waiting long enough and a
>> race condition was occurring.
>>
>> The problem with this of course is that it does not guarantee to work
>> around the problem. Different machines have different performance
>> characteristics, we run the unit tests using Hudson on many different
>> machines, plus we don't want to wait too long for the unit tests to
>> complete :-) i left the waiting period to be one second...
>
> Agree. I will take a look as soon as I can (I'm on travel for the next
> two weeks, starting in Prague now :-)). We delayed the 1.7.0 promotion
> until I can make it work on Jersey correctly...which mean I need o
> execute soon :-)
>

Wow, i feel honored that you have done that :-)


>
>>
>> Incidentally it appears we have a similar problem with the LW HTTP
>> server shipped with SE 6 Update 3 (but not with the http.jar shipped
>> with Jersey). The LW HTTP server unit tests when run on SE 6 were
>> blocking, Jakub put a sleep statement in after the server.start() and
>> they work :-)
>
> Interesting :-)
>
> BTW I've realized that SelectorThread extends Thread (something I've
> forgot for a long time), so the current code can be simplified....
>
> More to come...
>

Great!

http://blogs.sun.com/sandoz/entry/a_grizzly_jersey

In the future i would really like to investigate integration of Grizzly
Comet support with Jersey. There are some interesting things one can
with the Scala language that could make Comet support really sweet.

Paul.

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109