db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "NetworkServerSessionManagement" by BryanPendleton
Date Thu, 25 May 2006 01:45:31 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by BryanPendleton:
http://wiki.apache.org/db-derby/NetworkServerSessionManagement

The comment on the change is:
Add section on freeThreads going negative

------------------------------------------------------------------------------
   * I think that it is confusing to use the {{{runQueue}}} as both a collection object and
as a thread wait queue, and it would be simpler and less error-prone to use two separate objects
for that.
   * I think that primitive methods like {{{getThreadList()}}} and {{{getFreeThreads()}}}
should be avoided, as they risk exposing too much of the implementation to callers, and allowing
race conditions to be accidentally introduced.
  
+ == freeThreads counter maintenance ==
+ 
+ As discussed earlier, there is no explicit collection object which contains
+ the set of threads which are currently idle, waiting for work to do.
+ 
+ Instead, the Network Server maintains an integer variable, called
+ {{{freeThreads}}}, to count the number of such threads. Immediately
+ before calling {{{runQueue.wait()}}}, the thread increments this counter,
+ and immediately after returning from {{{runQueue.wait()}}}, the thread
+ decrements this counter.
+ 
+ However, it is also possible for the thread to be interrupted, in which
+ case it doesn't return normally from {{{runQueue.wait()}}}, but rather
+ throws an {{{InterruptedException}}} from that method.
+ 
+ The {{{getNextSession()}}} method handles this possibility by catching
+ the {{{InterruptedException}}} message, and decrementing the counter in
+ this case as well.
+ 
+ However, when the Network Server restarts, it also unconditionally sets the
+ counter to 0. This means that there is a latent problem, which I uncovered
+ when I experimented with having the Network Server interrupt the threads
+ during restart processing. What happens is as follows:
+  * The Network Server restarts
+  * During restart processing, it interrupts the {{{DRDAConnThreads}}}
+  * The Network Server then sets the freeThreads counter to 0
+  * The threads which have been interrupted then awaken, catch the {{{InterruptedException}}},
and decrement the counter.
+ 
+ The counter then goes negative, and becomes completely useless. 
+ The Client Thread thinks that there are plenty of free threads, 
+ because the free threads counter is not 0, so it never starts any 
+ new threads, but in fact there aren't any free threads (there are -1 or
+ -2 or some number like that).
+ 
+ The symptom is that, after the Network Server is restarted, assuming that
+ it interrupts the threads during restart processing, it then never starts
+ any new threads, although it continues to accept new TCP/IP connections
+ and creates new {{{Session}}} objects.
+ 
+ The fix, I believe, is simply to remove the unconditional setting of the
+ freeThreads counter to 0 in the restart processing, and let the incrementing
+ and decrementing logic in {{{getNextSession()}}} handle all the maintenance
+ of this counter.
+ 
  == Changing the Session Management code ==
  
  I think that there are a number of problems in the Session Management code

Mime
View raw message