Salut,
fixed. Can you try it and let me know what you are getting? I suspect
you have checked out the workspace, so just svn up and rebuild.
Thanks!!
-- Jeanfrancois
Jeanfrancois Arcand wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>