Salut,
I've filled:
https://grizzly.dev.java.net/issues/show_bug.cgi?id=409
I confirm this is a regression. The issue is our internal object aren't
recycled properly, corrupting the normal processing. I'm testing a fix
right now.
Thanks
-- Jeanfrancois
Jeanfrancois Arcand wrote:
> Salut,
>
> Abey Tom wrote:
>> Salut,
>>
>> I have something more to add to the Issue 2 mentioned in the previous
>> mail.
>> I apologize for the mail chain as I found this after I posted the
>> previous
>> mail.
>
> No apologize!! Your analysis are really helpful. I just don't understand
> how Request/Response get mixed (working on it).
>
>> The above issue 2 can be reproduced even without the test
>> program.....just
>> with the browser. All we need is to hit(or refresh) the
>> servlet(http://<ip:port>/grizzly-comet-chat/chat) 5 times and the 6th
>> time
>> you will get the issue, since we have 5 ProcessorTasks initialized by
>> default. When I hit(refresh) the url 5 times the field
>> 'errorException' will
>> be set in all the 5 Response Objects. This issue happens only if we
>> hit the
>> servlet directly.
>> In case we hit the welcome page(http://<ip:port>/index.html) , first
>> it will
>> request for the static resources. In the below code snippet from
>> com.sun.grizzly.arp.DefaultAsyncExecutor.preExecute()
>>
>> public boolean preExecute() throws Exception{
>> processorTask.preProcess();
>> // True when there is an error or when the (@link
>> FileCache} is
>> enabled
>> if (processorTask.parseRequest()){
>> finishResponse();
>> return false;
>> }
>> return true;
>> }
>>
>> the method finishResponse() will recyle the Response instance for static
>> resources. Since we have more than 5 static resources(png,js,css) etc all
>> the Response instances will be recycled before servicing the servlet
>> request......everything works fine.
>> This recycling is not happening in case when we hit the servlet directly.
>> Please feel free to revert if you need any furthur information.
>
> There is clearly an issue. Can you file one here:
>
> https://grizzly.dev.java.net/issues/
>
> It seems we have regressed with comet when it is time to postExecute the
> Request/Response from 1.9.8. We have made an optimization but it seems
> to have created that regression.
>
> Many thanks
>
> -- Jeanfrancois
>
>
>>
>> Thanks,
>> Tom
>>
>> Abey Tom wrote:
>>> Salut,
>>>
>>> I ran into a couple of more issues now.I think these are related to the
>>> above issue. I've created a Java Program to hit the WAR(the same one I
>>> attached in my first mail). Please find the Java File attached. This
>>> program invokes http://www.nabble.com/file/p23229414/CometTest.java
>>> CometTest.java the AjaxCometServlet. I'm also passing a unique
>>> clientId as
>>> the request parameter, which i'm logging at both the client-side and
>>> server-side.
>>> ======Issue 1======
>>> I start the server(grizzly-comet-webserver) and In the client program I
>>> spawned 20 threads and hit the application and then stop the client
>>> after
>>> getting some responses. Everything works fine.
>>> Then I just spawned a SINGLE thread and hit the application and found
>>> that
>>> the request parameter 'clientId' logged in at the server-side is
>>> different
>>> from the one which is passed from the client-side. This server-side
>>> clientId is one of the clientIds which came as part of the first 20
>>> threads.
>>>
>>> So in the method GrizzlyAdapter.service(Request, Response), when I
>>> inspected the variable com.sun.grizzly.tcp.Request req, the value of
>>> req.parameters.decodedQuery is the wrong clientId and req.queryMB has
>>> been
>>> set to the correct clientId. So request.getParameter("clientId") return
>>> the wrong one(old one from some previous request).
>>>
>>> ======Issue 2 ======
>>> In this above case also server is not sending any response to the
>>> client.
>>> So when I inspected the variable com.sun.grizzly.tcp.Request req in
>>> method
>>> GrizzlyAdapter.service(..) , the variable req.errorException is not NULL
>>> which causes ClientAbortException being thrown from the method
>>> com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(boolean). This
>>> method Response.setErrorException(Exception)is bieng invoked when
>>> SocketChannelOutputBuffer.flush() throws IOException when I
>>> disconnect the
>>> first 20 threads(terminate the client java program).
>>>
>>> How do we make sure that we get new Request() and new Response() each
>>> time
>>> we start a new Client Request?
>>>
>>> Please feel free to revert if you need any furthur information.
>>>
>>> Thanks,
>>> Tom
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>