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: Tue, 04 Dec 2007 14:52:01 +0100

Jeanfrancois Arcand wrote:
> Salut,
>
> Paul Sandoz wrote:
>> Hi,
>>
>> I added some simple tests for HTTP methods, see:
>>
>> com.sun.ws.rest.impl.container.grizzly.HttpMethodTest
>>
>> When all tests are enabled all tests pass. However if i only enable
>> the testPost test (which is the case for the unit test class in the
>> trunk) then it fails.
>>
>> There appears to be an initialization issue with the Grizzly server
>> w.r.t to a first HTTP request that contains a message body. Subsequent
>> HTTP requests that contain a message body work fine. You can
>> experiment by enabling/disabling and duplicating various tests.
>
> OK I suspect the problem is with the GrizzlyRequest/ResponseAdaptor.
> Will take a look.
>

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

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

Paul.

> Thanks
>
> -- Jeanfrancois
>
>>
>> Paul.
>>
>> Paul Sandoz wrote:
>>> Hi,
>>>
>>> I have integrated things into the trunk.
>>>
>>> The bug with the query string is because the URI constructor used URI
>>> encodes URI component values, thus percent encoding was happening twice.
>>>
>>> I looked at the JavaDoc for:
>>>
>>> com.sun.grizzly.tcp.Request
>>>
>>> but there is no description for the URI information returned by these
>>> methods:
>>>
>>> decodedURI()
>>> requestURI()
>>> unparsedURI()
>>> query()
>>> queryString()
>>>
>>> So i printed out all those values for a request at it appears
>>> unparsedURI().toString() is a URI, in raw URI encoded form,
>>> containing the URI path and URI query components.
>>>
>>> So i replaced all the code after constructing the base URI with:
>>>
>>> this.completeUri = baseUri.resolve(request.unparsedURI().toString());
>>>
>>> and the test now passes.
>>>
>>>
>>> Some questions/comments:
>>>
>>> - do you have or intend to provide a core Grizzly jar rather than
>>> four separate jars?
>>>
>>> - i am going to create a GrizzlyServer server factory so it is possible
>>> to deploy resources and create and start a "default" SelectorThread in
>>> just one line of code:
>>>
>>> SelectorThread thread =
>>> GrizzlyServer.create("http://localhost:9997");
>>>
>>> - i notice that in the unit test you put a sleep statement after the
>>> thread that calls the SelectorThread.startEndpoint is called. It would
>>> be very useful to have a blocking method on SelectorThread that
>>> started the endpoint in a new thread and waited until the endpoint
>>> said it is ready. Another way is for the method to return a
>>> Future<Boolean>.
>>>
>>> Paul.
>>>
>>> Jeanfrancois Arcand wrote:
>>>> Salut,
>>>>
>>>> attached is the first patch. You will need to pullout the Grizzly's
>>>> jat from here[1]. Why first, it's because there seems to be an
>>>> encoding problem (which was also with Grizzly 1.0) I need to look at
>>>> because a simple query test fail. I'm attaching the tests as well so
>>>> you can take a look to see if the bug is in Grizzly or not. My guess
>>>> is not. I think the way the response is constructed is the problem
>>>> as bytes as written without any char to bytes conversion.
>>>>
>>>> At least now you can use Grizzly 1.6.x and find more bugs :-).
>>>>
>>>> Let me know what you think.
>>>>
>>>> A+
>>>>
>>>> -- Jeanfrancois
>>>>
>>>> [1] http://download.java.net/maven/2/com/sun/grizzly/
>>>>
>>>> Paul Sandoz wrote:
>>>>> Jeanfrancois Arcand wrote:
>>>>>>> My preference would be to only support the latest greatest stable
>>>>>>> Grizzly.
>>>>>>
>>>>>> Agree...and the latest is faster :-)
>>>>>>
>>>>>> I've ported the code (it compile with the latest Grizzlies jars)...
>>>>>
>>>>> Great!
>>>>>
>>>>>
>>>>>> now I don't recall how to test it (as usual)....any pointers of
>>>>>> what I should run/try before submitting the patch will be helpful!
>>>>>>
>>>>>
>>>>> Perhaps the best thing to do is copy a unit test from the LW HTTP
>>>>> server.
>>>>>
>>>>> See the test package:
>>>>>
>>>>> com.sun.ws.rest.impl.container.httpserver
>>>>>
>>>>> and the classes:
>>>>>
>>>>> AbstractHttpServerTester
>>>>> QueryParamTest
>>>>>
>>>>> You could copy these classes to the package
>>>>>
>>>>> com.sun.ws.rest.impl.container.grizzly
>>>>>
>>>>> and modify accordingly.
>>>>>
>>>>> Note that we do plan to improve the unit testing framework to make
>>>>> it easy to test independent of the container but we are not their
>>>>> yet so it is necessary to duplicate such tests.
>>>>>
>>>>> Paul.
>>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>

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