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 Fri, 05 May 2006 17:34:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1219?page=comments#action_12378079 ] 

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

Hi Bryan,

Here are the answers to your questions:

1) You said you were able to reproduce this outside the harness; can you post a brief description
of the steps, so that I can experiment with the code in my environment?

To run the test jdbcapi/checkDataSource.java without using the test harness, I started network
server and then used the following command to run the test:  
java -Dderby.system.home=C:\deepa\Derby\derby_testing\nwserver -Dframework=DerbyNetClient
-Dij.database=jdbc:derby://localhost:1527/wombat;create=true org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource

The test hangs intermittently and the place where the test hangs is in one of the getConnection
methods. The hang location varies in different runs but is always in the getConnection method.
I can repro it quite easily (~ 1 out of 5 runs hang) on my machine. I hope you are able to
repro it too.

2) Were you running with sane=true, or sane=false? If sane=false, can you try sane=true?

I was running with sane=true. The debug output can be seen in the derby.log in the attached
zip file (drda_traces_050206.zip)

3) You mentioned that the server does not get any data in DDMReader.fill, and thinks the client
has disconnected. Can you expand on how you came to that conclusion? Were you able to see
an IOException being thrown? Can you get a dump of that exception? After the exception has
been thrown (i.e., during the hang), does netstat think that there is still an active TCP/IP
connection between the client and the server? 

I was looking at the server debug trace from a normal run (without hang) and when the test
hangs. On comparing both and also looking at the client and server traces, I found the following
from the trace files:
* Client trace stops with send of EXCSAT and ACCSEC (client_trace.txt_sds_1)
* At the server side, I can see an empty trace file is created but cannot see the EXCSAT and
ACCSEC as the last entries in any trace file (Server10.trace, Server9.trace)
* In the debug trace of server, the last trace is "Ending connection thread". I added few
other traces in DDMReader.fill and DRDAConnThread.run  and found that server is actually reaching
the end of the input stream (actualBytesRead == -1) without reading any data (totalBytesRead
is 0) and hence calls "agent.markCommunicationsFailure ("DDMReader.fill()", "InputStream.read()",
"insufficient data", "*");" The connection thread catches this disconnect exception and exits
normally thinking the client has disconnected. The debug traces from a successful run show
 that network server starts a new connection thread at this point.

>From the above, I thought of following possibilities:
* server is not getting a set of data from the client. data is lost. this looks unlikely 
* server thread is reading a wrong stream (from an already closed connection) and thinking
the client does not have more data and that it has disconnected. 
* session state associated with the server thread is wrong. Instead of starting new session,
server is thinking it has an active session and tries to process commands for the active session

I am just throwing in some ideas which come to me and could be totally off here. I plan to
look at this some more and will post if I find something else.

There are no IOExceptions at server or client. The IO exception seen in the client trace file
(client_trace.txt_sds_1) is because I killed network server after the test was hanging for
a long time. This was just to reconfirm where the client is hanging. 

In netstat output, I can see listening and established statuses for both client and server
process during the hang. 

Ouput of runtimeinfo command: 
--- Derby Network Server Runtime Information ---
---------- Session Information ---------------
Session # :10


-------------------------------------------------------------
# Connection Threads : 2
# Active Sessions : 1
# Waiting  Sessions : 0

Total Memory : 3694592  Free Memory : 2649768

Hope this helps.

> 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
>     Priority: Minor
>  Attachments: client_stack_trace_050306.txt, drda_traces_050206.zip, server_stack_trace_050306.txt,
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