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=37896>. 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=37896 ------- Additional Comments From [EMAIL PROTECTED] 2005-12-15 00:25 ------- Okay I had a look at the new code and I'm pretty sure the problem will still manifest itself. The problem isn't with the code perse but I think it's a problem with the design of the replication. Since the replication is in-line with the HTTP request (seems like new session requests are inline even in asynch mode), if something bad happens to the replication socket which causes it to hang, it will block that thread (presumably until SO_TIMEOUT which is usually 2 minutes). If a subsequent request comes in for a new session, it will try to do the same thing but it needs to aquire a lock on the DataSender object via sendMessage(); therefore, this thread will now block until the previous thread timesout. As a result a lot of threads may backup while waiting for the original socket to timeout. Note that this could happen even in pooled mode, if all 300 threads had their own 300 replicator sockets, and each sat there waiting to timeout for 2 minutes, then there wuld be no more threads available (assuming I'm maxed at 300 threads). The only things I can really think of to resolve this is to have the replication on a separate thread to the http requests. Of course maybe I'm just mis-reading the code and everything I'm saying might be wrong... -- 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]
