Coyote Performance Problems with HTTP1.1

2003-09-10 Thread Steve Appling
Chunked encoding with the coyote http1.1 connector seems to be very inefficient. I have 3 major comments about it which I will summarize, then explain in more detail for those interested. 1) There are some performance problems with the current implementation of chunked encoding. 2) I would l

Re: Coyote Performance Problems with HTTP1.1

2003-09-10 Thread Steve Appling
Remy Maucherat wrote: > Look, there's no reason to start whining. Adding a lower level buffering > (using a ByteChunk maybe) is nearly trivial, and since you seem to know > what you're doing, you could have done in less than the amount it took > you to write your email. > I'm not convinced it's the

[PATCH] Performance Problems in Coyote Chunking

2003-09-11 Thread Steve Appling
The following patch combines the 3 packets that were generated for each chunk into just one packet. There are more optimizations elsewhere - I'll keep looking. Patch of org.apache.coyote.http11.filters.ChunkedOutputFilter from 4.1.27 src. --- ChunkedOutputFilter.java.orig 2003-07-31 19:29:00.000

Re: [PATCH] Performance Problems in Coyote Chunking

2003-09-15 Thread Steve Appling
Remy Maucherat wrote > After testing and benching, implementing buffering at the lower layer is > much better, as it avoids introducing complexity in all the levels of > processing, and is more powerful. The performance impact of the new > behavior is minimal (using a worst case scenario of a stat

[PATCH] fix compression="on" option on coyote connector

2003-09-17 Thread Steve Appling
Currently the option for compression="on" in the coyote connector is broken (see bug 18073). The solution presented in the patches attached to that bug seemed overly complicated. Here is an alternate patch that also fixes the problem. This patch changes 3 things: 1) Decreases the minimum compres

RE: [PATCH] fix compression="on" option on coyote connector

2003-09-17 Thread Steve Appling
Henri Gomez wrote: > Are you sure you want to compress content less than 2k ? > > BTW, you could use compression property for your purpose. You are correct, the property works fine. > > 3) Added application/x-javascript as a default compressable > >type. Now it allows all mime types starting wi

RE: [PATCH] fix compression="on" option on coyote connector

2003-09-17 Thread Steve Appling
Stefan Bodewig wrote: > In short, Netscape 4 probably won't work at all, MSIE seems to have > trouble unless you have a certain fix installed. All others should > work (even for the JavaScript case). > > The mod_gzip author recommends not compressing anything for Netscape 4 > at all. > There is a

RE: [PATCH] fix compression="on" option on coyote connector

2003-09-18 Thread Steve Appling
OK - here's a simple patch that just fixes the problem and doesn't change anything controversial :) I will be glad to make the changes to include two new attributes on the connector to specify the list of uncompressible mime types and uncompressible user agents if a committer is willing to conside

Coyote Connector - Disabling compression for a specific servlet

2004-11-04 Thread Steve Appling
I have an application where I would like to disable gzip compression for a few specific pages / servlets. I originally planned to use a servlet filter to remove gzip from the accept-encoding header on the request, but this won't work. The container code that needs to check this (isCompressable

Problem resolving TagExtraInfo class right after startup

2004-11-18 Thread Steve Appling
We are occasionally having problems when compiling a JSP soon after Tomcat has started. It results in a compile time exception starting with " Failed to load or instantiate TagExtraInfo class: org.apache.taglibs.standard.tei.ForEachTEI" I believe this is only happening when the JSP needs to be