[ http://issues.apache.org/jira/browse/DERBY-1817?page=comments#action_12433610 ] Bryan Pendleton commented on DERBY-1817: ----------------------------------------
I looked at 1817-2.diff and I think it is a good change. I think that moving this logic from ClientThread to NetworkServerControlImpl is the right way to go; I had tried several variants that were quite similar to this as part of working on DERBY-1326. The code is simpler and cleaner after this change. My only substantive comment is that I think, with this change, you can now encapsulate the thread list entirely within NetworkServerControlImpl, because no other class now needs access to these server control internals. That is, I think you can remove the getFreeThreads, getThreadList, etc. methods from the NetworkServerControlImpl class because they were there only to allow that access from ClientThread which you have now removed, and so you can now hide the ThreadList inside NetworkServerControlImpl and not expose these internals. Thanks for working on this problem! > Race condition in network server's thread pool > ---------------------------------------------- > > Key: DERBY-1817 > URL: http://issues.apache.org/jira/browse/DERBY-1817 > Project: Derby > Issue Type: Bug > Components: Network Server > Affects Versions: 10.2.1.0 > Reporter: Knut Anders Hatlen > Assigned To: Knut Anders Hatlen > Attachments: 1817-2.diff, 1817.diff, 1817.stat > > > If there is a free DRDAConnThread when a client connects to the network > server, the session is put into a queue from which one of the free > DRDAConnThreads can pick it up. However, if another client connects after the > session was put into the queue, but before the DRDAConnThread has picked it > up, one might end up with more sessions in the queue than there are free > threads. This can lead to hangs like the ones that we currently see in many > of Ole's tests (for instance checkDataSource - > http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/440518-derbyall_diff.txt). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
