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 Wed, 10 May 2006 01:08:07 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1219?page=comments#action_12378794 ] 

Deepa Remesh commented on DERBY-1219:
-------------------------------------

Hi Bryan, 
We seem to be thinking of the problem differently. I am just thinking aloud to explain how
I understood the scenario:

I think the scenario is: 

One of the threads have asked to restart the server and this "restart" includes:
1. a) close all sessions in runQueue b) clear runQueue
2. a) close all threads in threadList b) clear threadList 
3. reload the embedded driver

(Note: 1a and 2a are not single steps)

This restart is in progress and we get a "new connection" from the client. We can do two things:
1. queue it by adding to the runQueue list
OR
2. a) create a new thread for the connection b) add it to threadList c) start the new connection
thread

In addition to this, we can also have other connection threads which are running.

Some cases I can think of which can cause hang are if we have actions overlapped as follows:
case1: restart_1a, restart_1b, new_conn_2a, new_conn_2b, restart_2a, new_conn_2c
case2: new_conn_1, restart 1a, restart 1b ...

In case 1, after we have added a new connection thread to the threadList, threadList is cleared
by restart thread and all threads including the new thread are marked closed. We then start
the new thread (new_conn_2c) and it exits because it finds it was marked closed.

In case 2, we queue up the connection request, runQueue is cleared during restart. So we miss
the request.

To me, the problem seems to be that we access the lists runQueue and threadList when a restart
is in progress. 

In case of thread shutdown, I think the way it currently works is that we mark the thread
as closed (set close = true). And next time, this thread is used, it checks if it was closed
and if so it ends itself without doing anything. As the thread will not do anything else once
it is marked closed, I am thinking it is okay to consider it as closed and not wait for it
to actually terminate.  To me, the culprits seem to be the lists maintained by the server.

Any thoughts/comments?

> 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