db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1219) jdbcapi/checkDataSource.java and jdbcapi/checkDataSource30.java hang intermittently with client
Date Tue, 09 May 2006 23:01:09 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1219?page=comments#action_12378772 ] 

Bryan Pendleton commented on DERBY-1219:
----------------------------------------

I think that waiting for the reload to complete is fine, but we'll need to figure out a way
to have a
positive confirmation that the threads have received their notification and shut themselves
down,
since, from a certain point of view, the essence of this bug is that calling DRDAConnThread.close()
simply asks a thread to shut itself down, but does not wait for that shutdown to actually
occur.

Such an algorithm would look something like:
  - call close on each thread
  - call interrupt on each thread
  - while the threadlist is not empty
        wait for a while

I'm always nervous about algorithms like this because of the need for an open-ended wait:
 - how do we know how long to wait?
 - what happens if we've waited a long time and the threads still haven't shut themselves
down?

The algorithms that I was proposing in my previous comment basically replace this
open-ended wait logic with a potential resource leak in the scenario where the old
threads for some reason don't respond to the request to shut themselves down.
That is, either we accept the risk of leaking away old threads, or we accept the risk
of waiting indefinitely for old threads, (or, I suppose, we figure out some way to be
VERY confident that we can shut the old threads down in a reasonable amount of time).



> 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