DO NOT REPLY [Bug 31328] - DeltaRequest unable to handle two concurrent requests per 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=31328. 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=31328 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #13003|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2004-11-25 23:25 --- Created an attachment (id=13542) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13542action=view) Code Cleanup; make getSize() synchronized Hi Filip, Thanks for putting the synchronized in the code in all relevant spots, it should work now. Sorry for not providing a proper patch. For some paranoia reasons I'd like to see a synchronized with the getSize() -- it accessed the actions variable, all other accesses have been synchronized, to this one should be synchronized as well. As far as I can see the code will not produce exceptions any more if there are parallel request in a session on one tomcat. THANK YOU VERY MUCH, FILIP! Just some possible optimizations if someone cares: After introducing the synchronized the some of the Exceptions (Unable to remove element) can no longer happen, it is safe to remove them. Also I think that the synchronized in the inner class AttributeInfo is not necessary as it is already called by synchronized methods of DeltaRequest. And I also removed one NoSuchElementException that can not be thrown by a simple remove(). A patch is included. I do not reopen this bug, but maybe you find time to test and apply this patch. A version like this is running in my production enviro -- 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 31328] - DeltaRequest unable to handle two concurrent requests per 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=31328. 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=31328 --- Additional Comments From [EMAIL PROTECTED] 2004-11-19 21:25 --- put in code to check for this, should be in 5.0.30 -- 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 31328] - DeltaRequest unable to handle two concurrent requests per 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=31328. 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=31328 DeltaRequest unable to handle two concurrent requests per session --- Additional Comments From [EMAIL PROTECTED] 2004-10-29 15:33 --- I put in synchronization of read/write on the tomcat 5.5 branch, this bug didn't contain a patch, rather a complete file, so I won't do anything with that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31328] - DeltaRequest unable to handle two concurrent requests per 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=31328. 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=31328 DeltaRequest unable to handle two concurrent requests per session --- Additional Comments From [EMAIL PROTECTED] 2004-10-26 06:50 --- For me this patch looks good. We are going to use it. Recommended for TC 5.0.30. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31328] - DeltaRequest unable to handle two concurrent requests per 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=31328. 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=31328 DeltaRequest unable to handle two concurrent requests per session [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-10-26 14:57 --- As mentioned a long long long time ago :) If you have two threads per session, consider the following scenario: Thread A goes to server S1 and Thread B goes to server S2, your session replication will now be faulty since there is no distributed locking. Adding in synchronization here, would mean that we are letting the user think that concurrent access is ok, which it isn't. What I do agree with is that the readExternal/writeExternal methods could be synchronized, to avoid corrupted methods. You must still realize, that you have two concurrent requests, there is nothing that guarantees the order of them. Hence synchronizing the entire class does not resolve anything really. Your fundamental problem is still that you have more than one thread modifying the session. I am marking the bug invalid, cause we are not supporting distributed locking hence could never put in a complete fix. A synchronized workaround Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31328] - DeltaRequest unable to handle two concurrent requests per 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=31328. 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=31328 DeltaRequest unable to handle two concurrent requests per session --- Additional Comments From [EMAIL PROTECTED] 2004-10-26 18:54 --- Filip, I agree that distributed locking is out of reach. But please consider the following: carefully designed clusters will use sticky session routing via mod_jk. So as long as the primary node ist available there will be no parallel usage of sessions via different nodes. But even then and even without frames etc. we see every now and then unintentional parallel usage by people e.g. using Return and afterwards the mouse button to send a form to the server. This will result in double sending of the form and this should not technically corrupt the session objects. Of course there is no guarantee, that all session data still makes sense for the application. So at least we should not corrupt the LinkedLists in the DeltaRequest. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31328] - DeltaRequest unable to handle two concurrent requests per 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=31328. 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=31328 DeltaRequest unable to handle two concurrent requests per session --- Additional Comments From [EMAIL PROTECTED] 2004-10-09 15:26 --- Created an attachment (id=13003) First improvement of DeltaRequest.java (not thread safe yet, but without exceptions) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31328] - DeltaRequest unable to handle two concurrent requests per 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=31328. 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=31328 DeltaRequest unable to handle two concurrent requests per session --- Additional Comments From [EMAIL PROTECTED] 2004-10-09 15:31 --- I've just added an attachment of DeltaRequest.java I now use for my production tomcat 5.0.27. The synchronized-statements avoid Exceptions on the sending side (like the NoSuchElementException I described) and on the receiving side (like EOFException that Rainer described). But it is not yet thread safe to solve the other problem with the writeExternal() / reset() that should be atomic. So it's still work in progress, but feel free to comment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31328] - DeltaRequest unable to handle two concurrent requests per 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=31328. 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=31328 DeltaRequest unable to handle two concurrent requests per session --- Additional Comments From [EMAIL PROTECTED] 2004-09-21 18:33 --- Yes, you are right. We have a cluster in production and every now and then a user doesn't wait for a request to complete and instead sends the same request again. Once a day it happens, that these two identical requests end only a few milliseconds away from each other. Then we get the following exception on the receiving side of replication, which indicates, that the replication packet is corrupt. Filip: I know that your opinion is to not support parallel access to a session. On the other hand it happens very quickly in reality, so at least we should make sure, that we don't break the session. I didn't go deeper into the code, so I'm not sure, how much work synchronization would be. ERROR [org.apache.catalina.cluster.tcp.TcpReplicationThread[1]] (DeltaManager.java:912) - Unable to receive message through TCP channel java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:448) at java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:2657) at java.io.ObjectInputStream.readInt(ObjectInputStream.java:900) at org.apache.catalina.cluster.session.DeltaRequest$AttributeInfo.readExternal(DeltaRequest.java:285) at org.apache.catalina.cluster.session.DeltaRequest.readExternal(DeltaRequest.java:200) at org.apache.catalina.cluster.session.DeltaManager.loadDeltaRequest(DeltaManager.java:385) at org.apache.catalina.cluster.session.DeltaManager.messageReceived(DeltaManager.java:898) at org.apache.catalina.cluster.session.DeltaManager.messageDataReceived(DeltaManager.java:762) at org.apache.catalina.cluster.tcp.SimpleTcpCluster.messageDataReceived(SimpleTcpCluster.java:576) at org.apache.catalina.cluster.io.ObjectReader.execute(ObjectReader.java:70) at org.apache.catalina.cluster.tcp.TcpReplicationThread.drainChannel(TcpReplicationThread.java:129) at org.apache.catalina.cluster.tcp.TcpReplicationThread.run(TcpReplicationThread.java:67) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
