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