DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=36541>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 ------- Additional Comments From [EMAIL PROTECTED] 2005-09-14 01:10 ------- Ok, I'm going to *explain* why I'm so upset about this. "There is heavily used public API in this heavily multithreaded application that are not thread safe and not documented clearly as such." You might as well put it on the front page - you've got a page of comments from various ASF people trying to explain to the world how that sentence (which is what it all boils down to) makes a hair of sense. Any other parts of the most commonly used API in the system, those things which are not only used on multithreaded applications but happen to be *heavily* used parts of the API, with a high risk of threading problems, happen to be? Because I'm looking at your response and wondering WTF you expect of developers - to walk through the spec and GUESS at which things you've decided to willfully misinterpret for the sake of shaving off a few hundred milliseconds that cause my live applications hell? I've been wondering what's caused this for ages now, and just *happened* to stumble across this. How dare *ANYONE* at the ASF claim a holier-than-thou attitude about a fork when something as simple and basic as this gets explained away, marked invalid, and ignored. You're experimenting with people's live applications, whom everyone's been encouraging to trust software written by authors who think a few hundred milliseconds on Joe's web app is more important than stability. Plain and simple. WTF are you doing to Tomcat? Is there anything more important than its reputation as a stable platform? If the ASF worked so bloody well, we wouldn't be seeing someone asking us to misread sections of the spec. There is *no* defence for this kind of behaviour in a server like this; there's loads of defence for the existence of the bug, to be sure - but none for this kind of response... So all the pointless crying about someone forking off looks a lot more, now, like you're getting exactly what you deserve for decisions which quite clearly diverge from the sane by several kilometers. Even rereading this, I can't get over it - a major bug in the support for multithreading, being ignored by its developers for a range of differently pointless reasons, resulting in a "hey, we'll make it configurable". Configurable? What, now I *want* to selectively cause data corruption? I didn't realise it was such a beneficial option to have on hand. Sure, some of our readers get 'teh suck', but hey, it's 8 milliseconds faster for the other guy. This is one of those bugs that goes out in e-mail, to just about everyone I know, with a note that says maybe we should be looking at alternative solutions to Tomcat in our live environment - because if this is the kind of judgement being used to build the application we're depending on to serve content, you can keep it. This all works so long as I don't have to question fundamental decisions about whether the software is well made, and up until now, I've never even considered the possibility of whether or not I should trust what comes out of the Tomcat dev team. Now I find out that a major bug that's been affecting our platforms was someone's little 'experiment'. I haven't got two fingers big enough to stick up at the moron who thought *that* explanation was a good idea. Fix it. Resolved my arse. And while you're at it, tell me what other areas of the "spec" I should be misinterpreting, and working around in my code. Crying about a fork? Reading this, you practically *deserve* one. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
