[ http://issues.apache.org/jira/browse/DERBY-1817?page=comments#action_12433636 ] Francois Orsini commented on DERBY-1817: ----------------------------------------
> It is true that maxThreads could potentially change after it has been copied into max and before the new thread is added to the thread list. This is what I meant Yes. > I don't think this is a problem since we could end up with more threads than maxThreads regardless of synchronization > (for instance by setting maxThreads to 3 when there are five threads). However, I don't see that expanding the synchronization should cause > any problems either, so I will update my patch. Great. > Thank you very much for looking at the patch! My pleasure Knut ;) > 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