tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kitching Simon <Simon.Kitch...@orange.ch>
Subject RE: Document cacheing - the story thus far.
Date Thu, 28 Sep 2000 09:33:13 GMT


> -----Original Message-----
> From:	Drew Kidder [SMTP:Andrew.Kidder@Tivoli.com]
> Sent:	Wednesday, September 27, 2000 4:06 PM
> To:	tomcat-user@jakarta.apache.org
> Subject:	Document cacheing - the story thus far.
> 
> Thank you all for your many suggestions.  However, none of them have
> worked 
> as of yet.  Let me explain the symptoms one more time, in case we're 
> barking up the wrong tree.  Here we go...
> 
> I have a servlet, which "manually" sends the file to the browser when a 
> particular link is clicked.  I am writing a 4MB buffer, and writing to an 
> OutputStream. If the user wants to throttle his download connection, I 
> first cut the buffer size to 500K, and then use the Thread.sleep(2000) 
> method after ever write to slow the process down a bit and allow other 
> things to go on.
> 
> Now, when I click on a link with download throttling disabled, a .pdf
> file, 
> it takes like 0.5 seconds for the "open it/save it" dialog box to 
> appear.  If d/l throttling is enabled, and I click on the same link, it 
> takes maybe 2-3 seconds for the "open it/save it" box to appear, but the 
> actual sending of the file is done at the same rate as the non-throttled 
> download.  What this says to me is that Tomcat or Apache is caching the 
> file in the background (at my slower rate), and then independently 
> returning the file on it's own.  This is obviously not the desired 
> behavior, as this method makes it look as if the server is slow, rather 
> than a controlled download slow-down.
> 
> The things I have already tried in an effort to fix this problem:
> 
> 1.  If "throttle" is on, use HttpServletResponse.setBufferSize(0) to turn 
> off the buffering.  [DOESN'T WORK]
> 2.  If "throttle" is on, use HttpServletResponse.setHeader(...) to set all
> 
> the headers related to chacheing to "off" or "no-cache" or whatever.
> [BUPKIS]
> 3.  flush() the output buffer after every write.  [ZIPPO]
> 
> So, if I want to have complete control over how fast that file gets sent
> to 
> the client, is this buffer resizing thing going to do the job?  Or are 
> there things that Tomcat/Apache thinks that it can do better, and the 
> actual file transfer is out of my hands?
> 
> Thanks again for all your ideas and help.  This has now become sort of a 
> personal mission to figure out what the heck is going on in Tomcat's brain
> 
> and how it interacts with the browser. I'm going to figure this out, if it
> 
> kills me.  :)
> 
> ------
> Andrew Kidder
> L3 SW/Support Engineer, IBU
> Tivoli Systems
> 
> 512-436-4544
> akidder@tivoli.com
> http://www.tivoli.com
> 
> 
	[Kitching Simon]  

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


Mime
View raw message