-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
On 11/11/2009 1:43 PM, André Warnier wrote: > Cae Fernandes wrote: >> Well, >> >> It's not about counting the bytes, but making the connection slower. >> Like, if I would output only a certain amount of bytes per second, i'd >> have >> to output them and make the thread sleep for a certain amount of >> miliseconds.That's why I mentiojned sleeping threads. > > Yes, but isn't *any* solution, in the end, going to have the same effect ? Er, yes. > I mean, suppose that you have a direct connection between Tomcat and the > client, and that the client is behind a very slow (physical) connection. > At some point, the webapp is going to want to output something to the > client, but all buffers will be full waiting for the client to receive > them, and whatever is sending them will have to wait. > Whether that wait is a sleep decided at the level of the application, or > at the level of the OS, is rather immaterial. The webapp/thread will > wait anyway. Correct. But it's a reasonable assumption that the client will be able to consume more bandwidth than you're trying to target as the limit. Otherwise, that's not exactly called "limiting" now is it? :) > The only way to avoid that would be to have, between Tomcat and the > client, some appliance (software or hardware) which would buffer the > Tomcat output and send it to the client at the rate it will accept, or > at the rate that you decide. > > An Apache front-end might be able to do that, if it has some add-on > module for the purpose. There are some, mentioned in Cae's original post: mod_curb and mod_cband. He's prefer a Tomcat-only solution, so we're focusing on that for now. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr7MKsACgkQ9CaO5/Lv0PDkLgCfahlw8abd8A09097pk3Q/ZUmi ABEAnRZEsQlOaVesmbLGLAvUd67MHmS4 =G31y -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
