DO NOT REPLY [Bug 12069] - Creation of more HttpSession objects for one previously timed out session
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=12069. 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=12069 Creation of more HttpSession objects for one previously timed out session --- Additional Comments From [EMAIL PROTECTED] 2004-03-15 15:36 --- Although you state that RFC 2109 doesn't discuss concurrent requests, browsers like MSIE 6 use them, so I think server should somehow treat this situation. I don't think that mantaining a list of old and new sessions would have any significant negative impact on performance since it is needed to check this list ONLY when the server gets an old session ID and cannot find existing session object for it. Then, prior to creating a new session object, it should check the list of old-to-new session IDs mapping whether there has not been already created a new session for the old session ID. I agree that it could be tricky to implement the list, e.g. to retain small size of the list. Server must remove obsolete mappings when they aren't needed anymore (to prevent inappropriate memory consumption). Why I think tomcat should treat concurrent requests? Well, the example for which I submitted the download link, is little bit uncommon. But still I think changing the architecture of the web app you are suggesting isn't right solution of the problem. Consider the following (very usual?) situation: One frameset with two or more JSP frames. Since the frameset's content isn't changing, it is normal to set some longer expiration time to it, isn't it? Now consider that the session is lost on the server (session timeout) and user wants to refresh the page. He isn't interested in the fact he refreshes a frameset, not a page. But what will do the browser? First it checks the expiration time of the top level page (==frameset). Because it is still valid (not expired), it uses concurrent connections to get the content of the frames. And now two or more sessions are created and later some data stored in session attributes are lost... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12069] - Creation of more HttpSession objects for one previously timed out session
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=12069. 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=12069 Creation of more HttpSession objects for one previously timed out session --- Additional Comments From [EMAIL PROTECTED] 2004-03-15 19:25 --- All patches gratefully received... ;) If you have frames that participate as part of the same web app, can you not include a (possibly nested) frameset as part of the app? That way the sesion will expire at the same time for everything. I agree that this would be a 'nice to have' but without a proposed patch this is unlikely to be implemented. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12069] - Creation of more HttpSession objects for one previously timed out session
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=12069. 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=12069 Creation of more HttpSession objects for one previously timed out session [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Enhancement Version|4.0.4 Final |4.1.30 --- Additional Comments From [EMAIL PROTECTED] 2004-03-14 20:23 --- The HTTP state management spec (RFC 2109) does not discuss concurrent requests. Implementing a solution to the problem you describe would be tricky. Tomcat would have to maintain a list of old and new sessions and check this in a thread-safe way when creating a new session because the old one expired. This isn't going to have positive impact on performance. Previous requests along similar lines have not been implemented. I am going to change this to an enhancement request for now but without a proposed patch from you or interest from a tomcat committer this is unlikely to be implemented. You might have better luck with changing the architecture of the web app that creates the concurrent requests. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12069] - Creation of more HttpSession objects for one previously timed out session
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12069. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12069 Creation of more HttpSession objects for one previously timed out session --- Additional Comments From [EMAIL PROTECTED] 2003-03-15 16:45 --- I seems to have run into this problem with Tomcat 4.1.12, seems related to bug number 11845. I don't know, is there a way to know is the bug is accepted or not? How can we know why the session expires in the first place? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12069] - Creation of more HttpSession objects for one previously timed out session
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12069. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12069 Creation of more HttpSession objects for one previously timed out session --- Additional Comments From [EMAIL PROTECTED] 2002-10-02 07:34 --- Hey, what is this bug list for? If there is a bug report without any reaction for more than one month, there must be something wrong. At least a notice we know about this issue, but we will not fix it in 4.x would be polite. An example: When I have submitted a bug to a cURL bug list, the problem was fixed the same day. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
