https://issues.apache.org/bugzilla/show_bug.cgi?id=48760
--- Comment #8 from Stefan Kendall <arcanef...@gmail.com> 2010-02-18 00:21:18 UTC --- (In reply to comment #6) > https://issues.apache.org/bugzilla/show_bug.cgi?id=45601#c3 sets out the > circumstances under which the patch would be applied and points to a resource > to help figure out the necessary information. If you choose not to go down > that > route, that is your choice. > > Without an understanding of why the problem occurs and how the patch addresses > it there is no certainty that the root cause will be fixed or that other users > won't see regressions. > > Given the patch does address it for you, there are ways to reduce the burden > of > running a patched Tomcat version to no more than a couple of minutes of > additional work per upgrade. Again, the users list can help with this. Mark, I will address your concerns in turn. 1.) This is clearly an issue *with Tomcat*. For every person that chooses to serve a large file through Tomcat, should they also lose months of productivity to obscure, hard to trace down bugs that have been documented and reproduced? As network connections and bandwidth continually improve, the chance that businesses choose to send down bigger, richer files is likely to increase (think larger images, swfs, etc.). As such, this is clearly an issue if Tomcat expects to continue being a viable Servlet container. Tomcat solves a number of problems for a number of people, but if it cannot support the growing trends in web development (more data, richer data), then surely it will fail. Failing to address this issue not only hurts the product as a whole, but it sets a dangerous precedent for all future bug finds. 2.) Would you like performance metrics with a week of constant load, or real world usage data to confirm my claims? I can provide all of that, but as I am not a Tomcat developer, I cannot give you a mathematical proof as to why the fix works. The original posters ideas were discarded, so I cannot say why exactly the fix works. I do know, however, that for two built deployments of Tomcat 1.6.16->latest, one with the fix and one without, I can reliably reproduce the problem on the unpatched version with load generation tools (and wget), and I cannot reproduce the problem on the patched version (even with unrealistically high load). 3.) So then, you agree that there's a simple solution to the root cause of my problem, and it's a small change to the source base? As an application developer, I cannot suddenly become responsible for the entirety of the Tomcat code base. If you extend this scenario, any small problem *you* or *I* can not understand thoroughly should be self-maintained, correct? As problems increase, the reliability of the main Tomcat distribution would then become questionable. Conclusion: I submit that unless the problem can be proven harmful (via whatever automated test systems currently exist, or real life usage data), then the patch should be implemented. If no such tests exist, or no one can prove the patch harmful to the stability of Tomcat, then why not implement? There is a strong business case to implement the patch, and there is a weak case against implementation. If this does cause regressions for any party, then they can log an issue as I did. Remember that the optimization has not always existed, so at some point, the implementation of the optimization DID cause regressions, but you just didn't see it. This optimization removal would be an undoing of a -problem- introduced into the tomcat source in 5.5, rather than an out-of-nowhere fix that may cause issues. Regressions weren't a concern in 5.5, and they shouldn't be a concern now, when real data is involved to prove the fix viable and the previous optimization unstable. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
