db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepa Remesh (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1219) jdbcapi/checkDataSource.java and jdbcapi/checkDataSource30.java hang intermittently with client
Date Mon, 08 May 2006 18:03:22 GMT
    [ 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


Mime
View raw message