[ http://issues.apache.org/jira/browse/DERBY-1219?page=comments#action_12378481 ]
Deepa Remesh commented on DERBY-1219: ------------------------------------- I ran the standalone repro with both your patches. I was not able to reproduce the hang on my machine after 25 runs with each patch. Thanks for the detailed explanation of the problem. I think I was reading some overlapping traces and was misled. After reading your description, I added more traces and confirmed that the run method breaks out because it finds that the thread has been marked closed. As you said, it seems not quite okay to just break out without informing the client. Maybe, it is expected that this code can reached only after client is already informed after an exception or at end of a session. A quick look at places where close method is called seems to indicate this. Both your solutions seem to work on my machine but I am not very clear about them. About solution 1 (skipThreads.diff) , it does not seem quite right to remove the cleanup code (code to close existing threads and clear threadList). If it is okay to reuse the same threads after a restart, then it should be okay to remove this cleanup code. Even then, I think the real cause of this problem could be somewhere else. I have not looked at solution 2 as you mentioned it does not work in all cases. Just sharing another thought which occurred to me after reading your descriptions. It looks like the new thread which was opened to serve the new connection gets added to threadList before the list is going to be cleaned up during restart. This causes the new thread to be closed unexpectedly when the server is restarted. I do not want to lead you down the wrong path. So I am looking at how/where threadList is accessed and if there could me some missing synchronizations here. I will post if I find something. > 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
