Long time processing in the DwrServlet.service()

[Dmitry Kudrenko]

Greetings

I am using DWR with Simple framework
(http://www.simpleframework.org/). It has own Simple API which is
different from servlet-api. But I use Adaptor pattern to convert
simple.Request to HttpServletRequest and HttpServletResponse to simple.Response.

Also I am using Reverse Ajax in my web application.

Simple request handler receives request and forwards it to the DWR
Servlet using DwrServlet.service(request, response) method. DWR
Servlet configured properly and it works.

Sometimes I have strange behavior: request is being processed 1 minute but
method on the class mapped to javascript works only 10 msec.

I received this statistic wrapping DwrServlet.service with timer1 and
adding timer2 to the my Java class.

timer1.maximum value = 1 minute (The maximum time is the same as maximum time for Reverse Ajax request)
timer2.maximum value = 10 msec.

This situation is hard to reproduce in my local version of the
application. But I have this statistic often in the live system. So it
is hard to debug it.

It seems the number of these errors depends on browser (can't
reproduce it with FireFox) and connection quality. (Not sure).

Have you idea where the request can be 60 sec in the
DwrServlet.service?

Thanks in advance.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[mikewse]

Hi Dmitry,

I would suggest you try your application in a regular servlet engine,
like f ex Tomcat or Jetty, and report back if you still have any
problems. Reproducing your error in a "standard" environment will make
it much easier for other developers on the list to help you.

BTW: What is your impression of Simple framework? (There doesn't seem
to have been much activity the last years.)

Best regards
Mike Wilson

> -----Original Message-----
> From: Dmitry Kudrenko [mailto:dmitry@...]
> Sent: den 12 maj 2008 12:56
> To: users@...
> Subject: [dwr-user] Long time processing in the DwrServlet.service()
>
> Greetings
>
> I am using DWR with Simple framework
> (http://www.simpleframework.org/). It has own Simple API which is
> different from servlet-api. But I use Adaptor pattern to convert
> simple.Request to HttpServletRequest and HttpServletResponse
> to simple.Response.
>
> Also I am using Reverse Ajax in my web application.
>
> Simple request handler receives request and forwards it to the DWR
> Servlet using DwrServlet.service(request, response) method. DWR
> Servlet configured properly and it works.
>
> Sometimes I have strange behavior: request is being processed
> 1 minute but
> method on the class mapped to javascript works only 10 msec.
>
> I received this statistic wrapping DwrServlet.service with timer1 and
> adding timer2 to the my Java class.
>
> timer1.maximum value = 1 minute (The maximum time is the same
> as maximum time for Reverse Ajax request)
> timer2.maximum value = 10 msec.
>
> This situation is hard to reproduce in my local version of the
> application. But I have this statistic often in the live system. So it
> is hard to debug it.
>
> It seems the number of these errors depends on browser (can't
> reproduce it with FireFox) and connection quality. (Not sure).
>
> Have you idea where the request can be 60 sec in the
> DwrServlet.service?
>
> Thanks in advance.
>
> --
> Best regards,
> Dmitry Kudrenko
> ARDAS group (http://www.ardas.dp.ua)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Dmitry Kudrenko]

Greetings, Mike

MW> I would suggest you try your application in a regular servlet engine,
MW> like f ex Tomcat or Jetty, and report back if you still have any
MW> problems. Reproducing your error in a "standard" environment will make
MW> it much easier for other developers on the list to help you.

Certainly it will be good, but unfortunately, I have not chance to do
it easily. And it is why I ask you for ideas (potential solutions)
about reason why/where DwrServlet keeps (can keep) request for a long
time. And have not chance to debug it because of it is hard to
reproduce this issue locally (with good network connection).

I have no ideas how to localize the problem in a short term and why
processing time the same with Comet request maximum connection time.

Maybe it is question to the developer mailing list, not sure...

MW> BTW: What is your impression of Simple framework? (There doesn't seem
MW> to have been much activity the last years.)

Simple framework was an engine of the original application I started
to support/rebuild several months ago. So, Simple framework was
inherited from previous developers. But, as for me, it is a good
solutions for project where you have a lot of _small_ requests to
server. For example, JBoss creates separate thread for every
connection and it is rather expensive operation if you have a lot of
small AJAX requests from 1000 and more clients.

Simple framework provides the article with comparisons of Simple's
vs Apache and Resin. http://www.simpleframework.org/performance/comparison.php

And it is not bad approach for Web2.0 applications where you have one
main page and other content is generated dynamically. And when you
need to provide high interactively with server using AJAX requests.

Also, about Simple framework community: Mailing list is not very
active. But you can receive the helpful answer/suggestion for your
question rather quickly.

Thank you

>> I am using DWR with Simple framework
>> (http://www.simpleframework.org/). It has own Simple API which is
>> different from servlet-api. But I use Adaptor pattern to convert
>> simple.Request to HttpServletRequest and HttpServletResponse
>> to simple.Response.
>>
>> Also I am using Reverse Ajax in my web application.
>>
>> Simple request handler receives request and forwards it to the DWR
>> Servlet using DwrServlet.service(request, response) method. DWR
>> Servlet configured properly and it works.
>>
>> Sometimes I have strange behavior: request is being processed
>> 1 minute but
>> method on the class mapped to javascript works only 10 msec.
>>
>> I received this statistic wrapping DwrServlet.service with timer1 and
>> adding timer2 to the my Java class.
>>
>> timer1.maximum value = 1 minute (The maximum time is the same
>> as maximum time for Reverse Ajax request)
>> timer2.maximum value = 10 msec.
>>
>> This situation is hard to reproduce in my local version of the
>> application. But I have this statistic often in the live system. So it
>> is hard to debug it.
>>
>> It seems the number of these errors depends on browser (can't
>> reproduce it with FireFox) and connection quality. (Not sure).
>>
>> Have you idea where the request can be 60 sec in the
>> DwrServlet.service?
>>
>> Thanks in advance.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[mikewse]

> MW> I would suggest you try your application in a regular
> servlet engine,
> MW> like f ex Tomcat or Jetty, and report back if you still have any
> MW> problems. Reproducing your error in a "standard"
> environment will make
> MW> it much easier for other developers on the list to help you.
>
> Certainly it will be good, but unfortunately, I have not chance to do
> it easily. And it is why I ask you for ideas (potential solutions)
> about reason why/where DwrServlet keeps (can keep) request for a long
> time. And have not chance to debug it because of it is hard to
> reproduce this issue locally (with good network connection).

Ok, but be aware that you will get less help with an unknown
environment. It could be helpful if you deployed some of the DWR demo
apps on your custom environment, to see if you get the same problem
there (that would rule out one unknown variable = your application).

> I have no ideas how to localize the problem in a short term and why
> processing time the same with Comet request maximum connection time.

You need to provide a lot more information about your scenario:
- DWR version?
- Which request are you talking about? (Originating from a call on
  a JavaScript proxy object or from a DWR Reverse Ajax poll?)
- Describe more about the call that you are timing, sequence of
  operations, normal behaviour and expected times.
- Can you snoop and provide a HTTP log from when the problem appears?

Also think about this:
- DWR's Reverse Ajax request is designed to "hang" in the server
  for one minute when in Full Streaming Mode. Is this what you are
  seeing?
- Can you try the app with Reverse Ajax disabled, or try other
  Reverse Ajax modes (Early Closing, Polling) ?
- Could you be hitting the Two Connections Limit?

> Maybe it is question to the developer mailing list, not sure...

No, the user list is appropriate for this.

> MW> BTW: What is your impression of Simple framework? (There
> doesn't seem
> MW> to have been much activity the last years.)
>
> Simple framework was an engine of the original application I started
> to support/rebuild several months ago. So, Simple framework was
> inherited from previous developers. But, as for me, it is a good
> solutions for project where you have a lot of _small_ requests to
> server. For example, JBoss creates separate thread for every
> connection and it is rather expensive operation if you have a lot of
> small AJAX requests from 1000 and more clients.

Yes, that makes sense. Although, JBOSS bundles Tomcat and Tomcat 6
supports non-blocking I/O which gets rid of the thread-per-connection
problem.

> Simple framework provides the article with comparisons of Simple's
> vs Apache and Resin.
> http://www.simpleframework.org/performance/comparison.php

Yes, I saw this article but all the software versions are quite
outdated so it would be interesting to see a comparison with modern
versions like Apache 2.2 Event MPM, Tomcat 6 NIO, etc.

Best regards
Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Dmitry Kudrenko]

Greetings, Mike

>> ..., I have not chance to do
>> it easily. And it is why I ask you for ideas (potential solutions)
>> about reason why/where DwrServlet keeps (can keep) request for a long
>> time. And have not chance to debug it because of it is hard to
>> reproduce this issue locally (with good network connection).

MW> Ok, but be aware that you will get less help with an unknown
MW> environment. It could be helpful if you deployed some of the DWR demo
MW> apps on your custom environment, to see if you get the same problem
MW> there (that would rule out one unknown variable = your application).

Yes, I know that and really don't wait for the ready solution. And
thank you a lot for your help and work you did/doing for DWR community.

Certainly, I will try to investigate the problem with standard JEE
way. I want to add Filter with timer to my test application to
calculate all request processing times.

MW> You need to provide a lot more information about your scenario:
MW> - DWR version?
Oops. Forgot to write. dwr-2.0.3

MW> - Which request are you talking about? (Originating from a call on
MW>   a JavaScript proxy object or from a DWR Reverse Ajax poll?)

I wanted to say request to the simple method in my Java class which is mapped to the
javascript.

MW> - Describe more about the call that you are timing, sequence of
MW>   operations, normal behaviour and expected times.

Server side:

I create DwrServlet instance and configure it using DwrConfig which is
implementation of ServletConfig

  DwrServlet dwrServlet = new DwrServlet();
  dwrServlet.init(new DwrConfig());

All requests mapped to DWR are processed by the following method:

protected void process(Request request, Response response) {
      // convert simple request/response to HttpServletRequest/Response
      HttpServletRequest req = new SimpleHttpServletRequest(request);
      HttpServletResponse res = new SimpleHttpServletResponse(response);

      long timePoint = new Date().getTime();
      try {
          dwrServlret.service(req, res);
      } catch (Exception e) {
          log.error("Error", e);
      } finally {
          long duration = new Date().getTime() - timePoint;
          StatisticManager.addValue(request.getPath(), duration);
      }
}

Statistic manager uses Map<String,
org.apache.commons.math.stat.descriptive.SummaryStatistics> to store
statistic information filtered by statistic name. In our case it is
request path.

I have simple Java class (called TalkerBean) which is mapped using dwr.xml to
javascript="Client" in a "script" scope.

class TalkerBean {
   ...
   public void send(String msg) {
      long timePoint = new Date().getTime();
      try {
      // do something;
      } finally {
          long duration = new Date().getTime() - timePoint;
          StatisticManager.addValue("Send method", duration);
      }
     
   }
   ...
}

Client side:

//call send method
Client.send(msg, options);

There are several other methods in Client. But the method "send" called
in the same time when Reverse Ajax requests started too.

All code is adapted for the example, so can have mistakes/mistyping...

And after some time of using the system I can see that the maximum
time of the "duration" = 60 sec. And it is the same as maximum
connection time of Reverse Ajax requests.

Unfortunately, I can't redeploy the system often to add logs
because of it is in use. It is why I want to add all necessary logs
before releasing new version one time to have enough information for
fixing this problem.

Have you an idea what should be checked?.. Thank you a lot for your
help.

MW> - Can you snoop and provide a HTTP log from when the problem appears?

I don't have time stamp when it occurred. But I didn't find any suspicious
logs.

MW> Also think about this:
MW> - DWR's Reverse Ajax request is designed to "hang" in the server
MW>   for one minute when in Full Streaming Mode. Is this what you are
MW>   seeing?

Certainly. but in the result I can see the following statistic:

Name                                    Num       Min     Max     Ave     Disp
--------------------------------------------------------------------------------
...
Send method                             74635     0       22      2       2
/dwr/call/plaincall/Client.send.dwr     74740     0       59999   268     3352
/dwr/call/plainpoll/ReverseAjax.dwr     30600     502     60000   2009    7070
...

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> - Can you try the app with Reverse Ajax disabled, or try other
MW>   Reverse Ajax modes (Early Closing, Polling)?

It seems the problem doesn't occurred when Reverse Ajax is disabled.
Better to say: "I didn't see this situation without 'Reverse Ajax'"
And it seems to be quite random and I can't be sure that it is so. But
looks like this.

MW> - Could you be hitting the Two Connections Limit?
Certainly I could, but it is client side issue, but we have long time
processing request in server side. Am I right?

>> MW> BTW: What is your impression of Simple framework? (There
>> doesn't seem
>> MW> to have been much activity the last years.)
>>
>> Simple framework was an engine of the original application I started
>> to support/rebuild several months ago. So, Simple framework was
>> inherited from previous developers. But, as for me, it is a good
>> solutions for project where you have a lot of _small_ requests to
>> server. For example, JBoss creates separate thread for every
>> connection and it is rather expensive operation if you have a lot of
>> small AJAX requests from 1000 and more clients.

MW> Yes, that makes sense. Although, JBOSS bundles Tomcat and Tomcat 6
MW> supports non-blocking I/O which gets rid of the thread-per-connection
MW> problem.

Certainly I agree with you. JEE technologies went forward and it is
excellent. I just told you my impression based on project I have. But I
can't suggest it for new applications when you can choose platform
based on modern/actual frameworks.

And Simple framework API is really simple and can be a good choice
for some kind of projects. Your application can be easy
installed/downloaded/redeployed just using simple-core-3.0.jar (176Kb)
in it. This small library gives possibility to create your own light
application server quickly.

>> Simple framework provides the article with comparisons of Simple's
>> vs Apache and Resin.
>> http://www.simpleframework.org/performance/comparison.php

MW> Yes, I saw this article but all the software versions are quite
MW> outdated so it would be interesting to see a comparison with modern
MW> versions like Apache 2.2 Event MPM, Tomcat 6 NIO, etc.

Yes, the article is outdated and the simple-core library is outdated
too. The latest release was 2 years ago :(. Maybe they have a reason
to stop active developing.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[mikewse]

> MW> You need to provide a lot more information about your scenario:
> MW> - DWR version?
> Oops. Forgot to write. dwr-2.0.3

There have been some small changes to thread wake-up for 2.0.4 so you
could try the Release Candidate 1 at
https://dwr.dev.java.net/servlets/ProjectDocumentList?folderID=9081

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

Nice explanation of your tests, and yes they make sense I think.
Use
  request.getPathInfo()
instead of getPath() in your next deploy as this is the value that
DWR bases its decisions on. Just to be sure.
(See UrlProcessor.handle)

> Name                                    Num       Min     Max
>     Ave     Disp
> --------------------------------------------------------------
> ------------------
> ...
> Send method                             74635     0       22  
>     2       2
> /dwr/call/plaincall/Client.send.dwr     74740     0      
> 59999   268     3352
> /dwr/call/plainpoll/ReverseAjax.dwr     30600     502    
> 60000   2009    7070
> ...
>
> 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.

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

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

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

> MW> - Could you be hitting the Two Connections Limit?
> Certainly I could, but it is client side issue, but we have long time
> processing request in server side. Am I right?

Yes, with the information you have now provided it seems this should
not be the cause of your problem.

Best regards
Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Dmitry Kudrenko]

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)


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[mikewse]

> 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();

Ah yes, my bad. It's the HttpServletRequest I was thinking about
so use req.getPathInfo().

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

Yes, and also please count in error/exception callbacks as this may
signal any error code returns.

Best regards
Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Dmitry Kudrenko]

Greetings, Mike

Could it be the same issue with
http://www.nabble.com/Dwr-2.0.3,-reverseAjaxEnabled-and-IE6-td16031191.html

>> 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();

MW> Ah yes, my bad. It's the HttpServletRequest I was thinking about
MW> so use req.getPathInfo().

I did, but the situation is the same. The PathInfo() is correct.

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

MW> Yes, and also please count in error/exception callbacks as this may
MW> signal any error code returns.

I did the number of errors in the client side = number of long time
requests. Where target method is not executed.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[mikewse]

Hi Dmitry,

> Could it be the same issue with
>
http://www.nabble.com/Dwr-2.0.3,-reverseAjaxEnabled-and-IE6-td16031191.html

Probably not. This only regards an IE bug that would
normally make the browser hang but not the server. And you are
seeing the DWR servlet hang in service() for 60 secs right?

> >> 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.
>
> MW> Yes, and also please count in error/exception callbacks
> as this may
> MW> signal any error code returns.
>
> I did the number of errors in the client side = number of long time
> requests. Where target method is not executed.

I'm not totally sure on what you mean here. Could you describe
your numbers in a bit more detail? (And the actual numbers are
interesting too)

Also:
- did you try 2.0.4?
- is your StatisticManager thread-safe (synchronized) or could
  numbers be distorted by simultaneous thread access ?

Best regards
Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Dmitry Kudrenko]

Hello, Mike
Thank you for your response.
>> Could it be the same issue with
MW> http://www.nabble.com/Dwr-2.0.3,-reverseAjaxEnabled-and-IE6-td16031191.html

MW> Probably not. This only regards an IE bug that would
MW> normally make the browser hang but not the server. And you are
MW> seeing the DWR servlet hang in service() for 60 secs right?

Yes. I saw this issue reproduced only with IE, but I am not sure that
it is only IE issue. And DWR servlet hangs in service() for 60 secs.

>> >> 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.
>>
>> MW> Yes, and also please count in error/exception callbacks
>> as this may signal any error code returns.
>>
>> I did the number of errors in the client side = number of long time
>> requests. Where target method is not executed.

MW> I'm not totally sure on what you mean here. Could you describe
MW> your numbers in a bit more detail? (And the actual numbers are
MW> interesting too)
I did the following:

Added separate statistic on server side for long-time processed
requests (more than 2 seconds) and other requests (less than 2 seconds).
* Normal /call/plaincall/Client.send.dwr
* Slow /call/plaincall/Client.send.dwr

Added statistic to the bean methods.
* SendMessage

Also I added counters on the client side, browser sends these
statistics to server when conversation (in the chat application) is
finished:
* send-requests
* send-errors
* send-callbacks

So, I have the numbers like the following:

                   Name                       Num     Min     Max      Ave
------------------------------------------------------------------------------
Normal /call/plaincall/Client.send.dwr        98      3       200      9
Slow /call/plaincall/Client.send.dwr          2       59999   60000    60000

SendMessage                                   98      2       180      6

send-requests                                 100     ...
send-errors                                   2       ...
send-callbacks                                98      ...

MW> Also:
MW> - did you try 2.0.4?
I will. The problem that Customer doesn't allow to restart system
often. I am waiting to apply modifications. I also want to send
exception description from the client to server side.

MW> - is your StatisticManager thread-safe (synchronized) or could
Certainly the StatisticManager is thread-safe.

MW>   numbers be distorted by simultaneous thread access ?
I think not, because we can check these numbers in several places.
--
Best regards,
Dmitry Kudrenko
ARDAS group (http://www.ardas.dp.ua)


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Dmitry Kudrenko]

DK> often. I am waiting to apply modifications. I also want to send
DK> exception description from the client to server side.
I reproduced this issue with IE. The DebugBar HTTP(S) tab shows me the
following:

POST /dwr/call/plaincall/Client.send.dwr HTTP/1.1

callCount=1
page=/webclient.html
httpSessionId=
scriptSessionId=BC2DC6A1CE3783D23B577C6EA8F54DBA396
c0-scriptName=Client
c0-methodName=send
c0-id=0
c0-param0=number:3844
c0-param1=string:n
c0-param2=boolean:false
batchId=3920

And there is no difference between success request and this one.

It seems the request fault with the following error:

throw 'allowScriptTagRemoting is false.';
//#DWR-REPLY
if (window.dwr) dwr.engine._remoteHandleBatchException({ name:'org.directwebremoting.extend.ServerException', message:'Failed to read input' });
else if (window.parent.dwr) window.parent.dwr.engine._remoteHandleBatchException({ name:'org.directwebremoting.extend.ServerException', message:'Failed to read input' });

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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[mikewse]

Hi Dmitry,

> >> I did the number of errors in the client side = number of long time
> >> requests. Where target method is not executed.
>
> MW> I'm not totally sure on what you mean here. Could you describe
> MW> your numbers in a bit more detail? (And the actual numbers are
> MW> interesting too)
>
> I did the following:
>
<snip>

>
> So, I have the numbers like the following:
>
>                    Name                       Num     Min    
> Max      Ave
> --------------------------------------------------------------
> ----------------
> Normal /call/plaincall/Client.send.dwr        98      3      
> 200      9
> Slow /call/plaincall/Client.send.dwr          2       59999  
> 60000    60000
>
> SendMessage                                   98      2      
> 180      6
>
> send-requests                                 100     ...
> send-errors                                   2       ...
> send-callbacks                                98      ...

Ah, nice summary! Makes total sense.

> I reproduced this issue with IE. The DebugBar HTTP(S) tab shows me the
> following:
>
> POST /dwr/call/plaincall/Client.send.dwr HTTP/1.1
>
> callCount=1
> page=/webclient.html
> httpSessionId=
> scriptSessionId=BC2DC6A1CE3783D23B577C6EA8F54DBA396
> c0-scriptName=Client
> c0-methodName=send
> c0-id=0
> c0-param0=number:3844
> c0-param1=string:n
> c0-param2=boolean:false
> batchId=3920
>
> And there is no difference between success request and this one.
>
> It seems the request fault with the following error:
>
> throw 'allowScriptTagRemoting is false.';
> //#DWR-REPLY
> if (window.dwr) dwr.engine._remoteHandleBatchException({
> name:'org.directwebremoting.extend.ServerException',
> message:'Failed to read input' });
> else if (window.parent.dwr)
> window.parent.dwr.engine._remoteHandleBatchException({
> name:'org.directwebremoting.extend.ServerException',
> message:'Failed to read input' });

Great! I think this will help us a lot. I'm guessing that this
exception is thrown from ParseUtil.java:110 while it is reading
the POST body from the request InputStream.
As these requests are delayed by 60 secs my next guess is that it
is waiting for data and times out. Is the SimpleFramework socket
possibly configured with a timeout of 60 secs? Could you configure
the Simple socket to another timeout value and try again?

Maybe you could also configure your SimpleReq->ServletReq adapter
to spy on the input stream and log what data is actually fetched
by DWR for the different requests, so we can see how much DWR is
actually fetching before giving up on the slow requests.

I'm also noting that the
  throw new ServerException
on line 110 isn't being logged, so we can't see the nested exception.

Joe: could we add logging of this exception?

Best regards
Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Joe Walker-3]

On Wed, Jun 11, 2008 at 8:43 PM, Mike Wilson <mikewse@...> wrote:

Great! I think this will help us a lot. I'm guessing that this
exception is thrown from ParseUtil.java:110 while it is reading
the POST body from the request InputStream.
As these requests are delayed by 60 secs my next guess is that it
is waiting for data and times out. Is the SimpleFramework socket
possibly configured with a timeout of 60 secs? Could you configure
the Simple socket to another timeout value and try again?

Maybe you could also configure your SimpleReq->ServletReq adapter
to spy on the input stream and log what data is actually fetched
by DWR for the different requests, so we can see how much DWR is
actually fetching before giving up on the slow requests.

I'm also noting that the
 throw new ServerException
on line 110 isn't being logged, so we can't see the nested exception.

Joe: could we add logging of this exception?

Yes, but I'm not keen on doing this to 2.0.

I'm just checking something for this into HEAD, can you try it out there?

Joe.