Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Message-Id: <4.3.2.7.2.20000929154506.00afd250@ausmail4.tivoli.com>
Date: Fri, 29 Sep 2000 15:49:53 -0500
To: tomcat-user@jakarta.apache.org
From: Drew Kidder <Andrew.Kidder@Tivoli.com>
Subject: RE: Document cacheing - the story thus far.
In-Reply-To: <OFB7ABB462.B94C50FE-ON86256968.00547769@tivoli.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Thanks for the tip about telnetting to the http port...that action pointed 
out that the servlet was actually sending back a redirection (which it was 
throttling), not just the straight file. I had modified the Location header 
to get rid of a nasty little problem with file renaming.  Apparently, that 
was causing it to forward the request, rather than just rename the file.

So the d/l throttling works now. However, my original problem stands.  If I 
download a file named "myfile.pdf", the servlet renames it to "<servlet 
name>.pdf".  It delivers the file correctly, just names it 
incorrectly.  Setting the location header fixed that problem, but broke the 
throttling.  Got any ideas on how I can fix the naming problem?

Thanks again for your help on the throttling thing.  I'm glad I was able to 
put this to bed before the weekend. :)


At 04:33 AM 09/28/2000 -0500, you wrote:

>         OK, I've looked at our code again; we have a
>         similar need to flush data to the client, as we
>         want to output progress messages in between
>         calling a bunch of time-consuming business
>         processes. I found that instead of a simple
>         flush, we have:
>
>         void flushPrintWriter( javax.servlet.jsp.JspWriter jw ) throws
>java.io.IOException
>         {
>             for ( int i = 0; i < 1000; i++ )
>                 jw.print(" ");
>             jw.flush();
>         }
>
>         I guess that at some point, one of us found that flush
>         needed some help. You might want to try this.
>
>         Also, you might want to see a bit more directly
>         what is happening; why not try
>
>         telnet yourwebserver yourport
>         GET /throttledpage.jsp
>
>         then watch the data coming back, just in case
>         your page is actually working but the problem
>         is in the browser somewhere...
>
>         Good luck hunting this one down...


------
Andrew Kidder
L3 SW/Support Engineer, IBU
Tivoli Systems

512-436-4544
akidder@tivoli.com
http://www.tivoli.com