DO NOT REPLY [Bug 34227] - Simultanenous HttpRequests with shared HttpSession can leave it unable to timeout
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=34227. 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=34227 --- Additional Comments From [EMAIL PROTECTED] 2005-03-31 11:36 --- It becomes a little bit more rational (although it is still impossible), as you are describing a scenario which wouldn't rely on a race condition incrementing the int. If the session field becomes null, then endAccess is not going to be called. The request objects are per thread, are fully independent, and I don't see any scenario (other than the session becoming invalid, in which case there won't be any problem, of course) when the session field would become null. -- 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]
DO NOT REPLY [Bug 34227] - Simultanenous HttpRequests with shared HttpSession can leave it unable to timeout
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=34227. 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=34227 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-03-30 13:16 --- On thing is for sure, we're not going to add any synchronization for this. If something goes away, it will be the call to endAccess (which was added due to *one* user whining about a stupid use case). I think a hack should be added instead (if the inactivity period gets too long or something). I do not understand the problem still: is it actually the accessCount int which ends up having the wrong value due to concurrent access ? That's actually almost impossible. -- 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]
DO NOT REPLY [Bug 34227] - Simultanenous HttpRequests with shared HttpSession can leave it unable to timeout
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=34227. 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=34227 --- Additional Comments From [EMAIL PROTECTED] 2005-03-31 03:19 --- (In reply to comment #6) On thing is for sure, we're not going to add any synchronization for this. If something goes away, it will be the call to endAccess (which was added due to *one* user whining about a stupid use case). I think a hack should be added instead (if the inactivity period gets too long or something). I do not understand the problem still: is it actually the accessCount int which ends up having the wrong value due to concurrent access ? That's actually almost impossible. Yes the accessCount within StandardSession is bumped up to 2 during concurrent request (StandardSession.access() increment call) and after both requests are completed it remains with value 1. The recycle on the CoyoteRequest is where endAccess is called that decrements. Somehow the second request no longer has the session object to call the endAccess the second time. Note: this does not always happen - hence race condition. I agree its difficult to time but a machine can do it easily via browser multiple background download calling servlets that execute in nearly equal time. I also agree that synchronizing is not a desired solution to this. -- 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]
DO NOT REPLY [Bug 34227] - Simultanenous HttpRequests with shared HttpSession can leave it unable to timeout
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=34227. 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=34227 --- Additional Comments From [EMAIL PROTECTED] 2005-03-29 21:36 --- It appears making StandardSession.endAccess() and StandardSession.access() synchronized would do the trick. -- 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]
DO NOT REPLY [Bug 34227] - Simultanenous HttpRequests with shared HttpSession can leave it unable to timeout
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=34227. 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=34227 --- Additional Comments From [EMAIL PROTECTED] 2005-03-30 00:58 --- We're obviously not going to sync that (which exists due to some fairly stupid spec requirements). If we can't find a solution, then we'll have to live with this issue. -- 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]
DO NOT REPLY [Bug 34227] - Simultanenous HttpRequests with shared HttpSession can leave it unable to timeout
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=34227. 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=34227 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-03-30 01:00 --- Actually, this means absolutely nothing to me: The race condition must be that the shared session object becomes unavailable to recyle and therefore is left with a positive access count. It seems you don't have a legitimate scenarion for your problem. - INVALID -- 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]
DO NOT REPLY [Bug 34227] - Simultanenous HttpRequests with shared HttpSession can leave it unable to timeout
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=34227. 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=34227 --- Additional Comments From [EMAIL PROTECTED] 2005-03-30 02:02 --- Yeah, well, regardless of the description, it's obvious from looking at the StandardSession code that the accessCount handling can't possibly work without a synchronized block or something like j.u.concurrent.atomic. -- 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]
DO NOT REPLY [Bug 34227] - Simultanenous HttpRequests with shared HttpSession can leave it unable to timeout
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=34227. 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=34227 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-03-30 04:00 --- (In reply to comment #3) Actually, this means absolutely nothing to me: The race condition must be that the shared session object becomes unavailable to recyle and therefore is left with a positive access count. It seems you don't have a legitimate scenarion for your problem. - INVALID Try a web page that has 2 javascript src tags each calling a servlet from the same web application container. The browser will hand that off to background threads (same ones used to download images) and bingo simultaneous servlet requests with same JSESSIONID cookie. So while yes its rather difficult for a user to pull off simultaneous requests on the same session a browser application has no such problem. You could probably see this one happen with a frame page with a servlet in each frame being called simultaneously as well, and multiple image generating servlets on a web page customizing output based on session. So I see more than one valid scenario for this. -- 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]
