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 21:18:23 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1817?page=comments#action_12433647 ] 
            
Knut Anders Hatlen commented on DERBY-1817:
-------------------------------------------

One "unfortunate" effect of my changes is that addSession() has become
thread safe. That is, multiple threads may invoke addSession()
concurrently without interfering with each other. Since addSession()
is only invoked from one thread (ClientThread), this is not strictly
necessary.

Also, the last sentence of this comment is not true as long as only
one thread invokes addSession():

  // Synchronize on runQueue to prevent other threads from updating
  // runQueue or freeThreads. Hold the monitor's lock until a thread is
  // started or the session is added to the queue. If we release the lock
  // earlier, we might start too few threads (DERBY-1817).

When I wrote that comment, I was thinking about multiple threads
invoking addSession(), but that doesn't happen. The way the current
code works, it would be enough to synchronize on runQueue when
comparing runQueue.size() and freeThreads, like this:

  boolean enoughThreads;
  synchronized (runQueue) {
      enoughThreads = (runQueue.size() < freeThreads);
  }

I am tempted to write a new patch which reduces the amount of code
synchronized on runQueue, but I also see the value of addSession()
being thread safe (in case the use of it changes, for instance by
having multiple ClientThreads listening to different ports). Does
anyone have an opinion on this?

Thanks.

> 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