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-09 17:37 ------- (In reply to comment #71) > Guys please .. Remy already said way back in #40 that he would look into > allowing this to be configurable :) I don't really see anything that says the real issue will be addressed. An out of the box Tomcat has to be configured not to have a bug? Plus, he said he would look into it and all this and that and that's fine, but no where does it reflect he believes there is an issue, and right now a bug caused by an uninformed decision remains. One, how do you synchronize calls with jsp:useBean with scope of session? Where else is session accessed in the Tomcat code without synchronizing that developers should be aware of? Is JSESSIONID stored in the session as well and where is it accessed? We need to make sure that access is synchronized. If we are going to talk about specifications and responsibilities lets talk about them, but logically and truthfully. There is more to this issue than can be addressed by: "It's the developers responsibility.". Do we need to file bugs for all of the other issues if this is going to remain invalid? I say that must be the case if this is to remain invalid. Personally I don't like the idea that "this was done as an experiment"... written in one of the comments above... in a system said to be "production quality" (Tomcat home page). The point is this: if it were an experiment it should have used an option to turn it on, but should not have been a default by any means. If a system has an apparent flaw that reduces it's stability and reliability and especially when it can be solved with a couple of lines of code.....a patch is a no brainer. This entire issue makes Tomcat currently invalid as there are sections of standard usage which can not be safe guarded against concurrency issues. If I have an issue where customers can get kicked out of the site after being logged in and the client asks me to fix it....I can't without changing the entire application, and by that I mean not using jsp:useBean calls in my JSP pages without wrapping them with other calls, so what's the point of using the tags in JSP if they can't be safe guarded without more work. I thought the point of the tags, EL, and other things is to make development quicker and to provide short cuts. My opinion: 1) Before a decision was made to change the synchronization of something which was currently synchronized when documentation for the underlying implementation explains there are issues with not synchronizing should not have only been discussed as to whether it was safe, logical, and correct, but should have been proved. 2) If it were to be an experiment, then it should have used an option to turn it on, and the default been the more correct implementation for the given situation. 3) When a problem is identified in a piece of software being promoted as production ready it should be handled. Not shaken off as INVALID. Where is the proof that unsychronized reads don't have issues. Examine the HashMap source code and write a few tests. You'll see with the bouncing index that a valid value can exist in the Map for a given key and that Entry not be located because null is returned. Thus a program relying on a session variable to be set will not be able to retrieve that session variable and take an entirely different path because of this....it's very simple........just read the code: public Object get(Object key) { Object k = maskNull(key); int hash = hash(k); int i = indexFor(hash, table.length); Entry e = table[i]; while (true) { if (e == null) return e; if (e.hash == hash && eq(k, e.key)) return e.value; e = e.next; } } between the time i is set from a call to indexFor if table is resized with all values null or all items are transfered and the given index for i is null then null is returned as soon as we step into the while loop. What that means is: If between the time i is set from indexFor and the HashMap is resized because of a write then there is a concurrency issue which affects the consistency of the application. How can this issue be worked around currently using Tags? If we need to file bugs on all the other places please let us know. If you would like some help with the other issues I would be willing to help, but my feelings are this should be changed back for the time being and we need a new release based on the latest release with only this change to the source. In the mean time all the other issues can be worked on as all of that will take more time than this change. Once those issues are dealt with then change it back and make sure the issue is documented on the front page of the Tomcat documentation. -- 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]
