[ http://issues.apache.org/jira/browse/DERBY-1817?page=comments#action_12433592 ] Knut Anders Hatlen commented on DERBY-1817: -------------------------------------------
Thanks Francois, I noticed that one myself too, that's why I created the local copy (max) instead of calling getMaxThreads() twice, as the original code did. I'm not sure I understand exactly what you mean by "seems like 'max' could be reset". Since it is a local int variable, other threads cannot change it, if that's what you mean by "reset". 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. 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. (Talking about synchronization in NetworkServerControlImpl, I also noticed that timeSlice has a mutex object, timeSliceSync, but only setTimeSlice() synchronizes on that object. Seems like a bug...) Thank you very much for looking at the patch! > 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.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
