Dmitry Kudrenko | 14 May 20:15

Re[2]: Long time processing in the DwrServlet.service()

Greetings, Mike

MW> There have been some small changes to thread wake-up for 2.0.4 so you
MW> could try the Release Candidate 1 at 
MW> https://dwr.dev.java.net/servlets/ProjectDocumentList?folderID=9081
Ok. I will try it in the 2nd stage after applying all other your
suggestions. To be sure that something is changed. :)

>> StatisticManager.addValue(request.getPath(), duration);

MW> Nice explanation of your tests, and yes they make sense I think.
MW> Use  request.getPathInfo() instead of getPath() in your next
MW> deploy as this is the value that DWR bases its decisions on. Just
MW> to be sure. (See UrlProcessor.handle)
There is no equest.getPathInfo() in simple. And it returns in the
Adaptor between simple and servlet APIs.

Hm.. I will check the req.getPathInfo();
Thanks

>> Interesting note: /dwr/call/plaincall/Client.send.dwr request started
>> more times than "Send method". But I didn't find Error 
>> message in the log.

MW> That's interesting. I wonder if DWR somehow could be picking up the 
MW> wrong handler for these 105 calls, and this is when you see the delay
MW> (would make sense with the Avg time you are seeing). Normally your
MW> Client.send calls should be routed through PlainCallHandler.

MW> It would be interesting to see the response data being returned
MW> for these delayed requests. It would be great if you could use
MW> Wireshark or some other HTTP tracer to examine this.

Unfortunately, I can't use Wireshark on live system. (Too many
restrictions for debugging :(( )

MW> You could also make your JavaScript code count the number of 
MW> successful callback returns and error/exception callback returns
MW> resulting from your Client.send.

Ok, yes. it should give us new information. I will add the counter to the
JavaScript and counter of request with duration more than 30 sec and
will compare them.

Thanks for your suggestions. I will try to apply all of these step by
step and will let you know about the result.

--

-- 
Best regards,
Dmitry Kudrenko
ARDAS group (http://www.ardas.dp.ua)

Gmane