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.
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.
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
>
--
View this message in context: http://www.nabble.com/Client-Stream-Update-Issue-with-Grizzly-Comet-tp23211261p23230252.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.