DO NOT REPLY [Bug 6460] New: - Problem of very long response time for servlet which don't return any response.

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6460>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6460

Problem of very long response time for servlet which don't return any response.

           Summary: Problem of very long response time for servlet which
                    don't return any response.
           Product: Tomcat 4
           Version: 4.0.1 Final
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: moliere@viveo-montpellier.com


Using a DummyServlet which logs a request for example.
This servlet doesn't need to return anything to the client machine (no HTML, XML or
whatever bytes array ).
Using Tomcat 4.01 this kind of servlet has very large response times (I guess that 
Catalina wait for any timeout before closing the stream).
Adding a dummy:
PrintWriter writer = response.getWriter();
writer.close();
(the same trick works with the getOutputStream() method of course).

is a workaround for this problem...
This problem occured with the new catalina architecture  because my code was
working properly with the Tomcat 3.2.3 release.

The problem induces an application response time increased by a *50 factor...

The bug doesn't seem to depend on the client VM because it was reproduced
running 1.3.1 Sun VM on Linux & Win2K machines.


The Tomcat 4.01 release used is the one found in the JBoss-Tomcat bundle, as I
previously used the Tomcat 3.2.3 coupled with Jboss 2.4.4.


The bug occurs only with this kind of servlet because the rest of my application
uses XML for transmitting values to clients & there 's no overhead (not viewable
without profiler tool...).

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>