db-derby-dev mailing list archives

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

        

Mime
View raw message