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 20:35:05 GMT
    [ 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
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
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,
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
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
> -----------------------------------------------------------------------------------------------
>          Key: DERBY-1219
>          URL: http://issues.apache.org/jira/browse/DERBY-1219
>      Project: Derby
>         Type: Test

>   Components: Network Server, Network Client
>     Versions:
>  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
> 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:
For more information on JIRA, see:

View raw message