[ http://issues.apache.org/jira/browse/DERBY-1219?page=comments#action_12378734 ]
Bryan Pendleton commented on DERBY-1219: ---------------------------------------- One strategy that occurred to me is that, rather than clearing and re-using the RunQueue and the ThreadList, we could have the restart processing set up a new RunQueue and ThreadList, and that way make a clean distinction between old sessions and threads, versus new sessions and threads. That is, try to avoid the problem of "a new session comes in, but gets handled by an old thread which is being closed", by teaching the code how to tell the difference between old and new threads and sessions. Some sort of restart algorithm like: oldRunQueue = RunQueue oldThreadList = ThreadList create new RunQueue and new ThreadList go through the old RunQueue and thread list and close and clean them up The idea being that, once we reach a certain point in Network Server restart processing, all new threads go onto the new thread list, and all new sessions go onto the new run queue, and it should be easier to tell the difference between old threads & sessions, which have been closed and should now die, and new threads and sessions, which are allowed to start doing new work. A similar, but not identical, idea would be to establish some sort of "generation" counter, which is incremented by one each time the Network Server restarts within a process, and instead of using the "close" API to shut down sessions and threads, use the idea of generations, so that a session or thread which is in an older generation is treated as dead and gets cleaned up, while new generation threads can start processing new generation sessions, and if a thread and a session ever found that their generations didn't match, they would know that something horrible had occurred and they could trigger a sanity check or assertion. Anyway, just some thoughts to keep the discussion going. > jdbcapi/checkDataSource.java and jdbcapi/checkDataSource30.java hang > intermittently with client > ----------------------------------------------------------------------------------------------- > > Key: DERBY-1219 > URL: http://issues.apache.org/jira/browse/DERBY-1219 > Project: Derby > Type: Test > Components: Network Server, Network Client > Versions: 10.2.0.0 > Environment: More often on jdk 1.5 or jdk 1.6 but hangs on jdk 1.4.2 as well > Reporter: Kathey Marsden > Assignee: Bryan Pendleton > Priority: Minor > Attachments: client_stack_trace_050306.txt, drda_traces_050206.zip, > interrupt.diff, server_stack_trace_050306.txt, skipThreads.diff, > testfiles_afterhang.zip, traces_on_hang.txt > > The tests checkDataSource.java and checkDataSource30.java > hang intermittently especially with jdk 1.5. > Attached is the test run output and traces when the server is started > separately. > 1) Enable checkDataSource30.java by taking it out of > functionTests/suites/DerbyNetClient.exclude. > 2) Run the test with client. > java -Dij.exceptionTrace=true -Dkeepfiles=true -Dframework=DerbyNetClient > org.apache.derbyTesting.functionTests.harness.RunTest > jdbcapi/checkDataSource30.java > Attachements: > testfiles_after_hang.zip - Test directory. > traces_on_hang.txt - Server side traces obtained by starting the server > separately before running the test. > I wish I had time to work on this right now as I would really like to see > this valuable test in the suite, but hopefully someone else will pick it up. -- 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
