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=28259>. 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=28259 Synchronous cluster very slow - select() bug ------- Additional Comments From [EMAIL PROTECTED] 2004-04-07 15:13 ------- I'm having a different opinion: it is well documented, that key.interestedOps() blocks waiting for select() to return - dependent on the JVM implementation. It is not a bug in the JVM! You call interestedOps() in TcpReplicationThread line 142 although there is a parallelly executing select() call in ReplicationListener. So the interestedOps () blocks the TcPReplicationThread until the select() in ReplicationListener returns. Since during that time OP_READ is not set, select might block a very long time. Of course setting tcpSelectorTimeout to a very small value looks like a workaround. But still it is not a safe solution: depending on the scheduling of threads on CPUs it might happen, that ReplicationListener calls select() again, before interestedOps() is able to set the new flags. I really think you need a design, - where you check for pending interestedOps or register calls before retrying select - where you "register" interestedOps or register calls as pending, afterwards call wakeup, then do the interestedOps or register call and finally "unregister" the calls. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
