db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1817) Race condition in network server's thread pool
Date Sat, 09 Sep 2006 10:33:23 GMT
    [ 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

        

Mime
View raw message