setting tracedirectory from the command line does not work

• Key: DERBY-3708
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Kathey Marsden
• Reporter: Kathey Marsden
• Component/s: Network Server
• Affects Version/s: 10.4.2.0, 10.5.1.1
• Fix Version/s: 10.4.2.0, 10.5.1.1

Description

I tried
java org.apache.derby.drda.NetworkServerControl tracedirectory /tmp
and got:
Trace directory changed to /tmp.

java org.apache.derby.drda.NetworkServerControl trace on
Trace turned on for all sessions.
Trace turned on for all sessions.

And the trace output was not redirected to the /tmp directory. The tracedirectory command seemed to be ignored.

Setting tracedirectory with the system property derby.drda.traceDirectory or with the NetworkServerControl api seems to work ok.

Comments

[Kathey Marsden]

Attached is a patch to fix this issue. The problem was that the client NetworkServerControl command was calling the server side method to set the trace directory instead of sending the command to the server.

Running tests now.

[Kathey Marsden]

suites.All and derbynetclientmats passed. Please review.

[Kristian Waagan]

I applied the patch, compiled and ran the changed test. Also started the regression tests (not finished).
Changes look good to me, +1 to commit.

Formatting nits (non-blockers):
 a) Inconsistent tab/space use in NetworkServerControlImpl (one line with spaces).
 b) Three lines with trailing whitespace in SecureServerTest.

[Kathey Marsden]

Thanks Kristian for looking at the patch. I fixed the white space/indentation issues and committed to trunk revision 669243

[Kristian Waagan]

Unset patch available flag. The only attached patched has been committed.
Setting the fix version and resolving remains (if work is done).

I also unset "Newcomer" in the component list and ticked the new "Newcomer" category box.

[Kathey Marsden]

Thanks Kristian for bringing the issue up to date.

I'll leave it open for now as I plan to backport to 10.4 and 10.3. That should happen shortly. I just got sidetracked with some other things.

Kathey

[Kathey Marsden]

I merged this fix from 10.4 to 10.3 and am getting a hang in SecureServerTest on Windows only. It seems to run fine on Linux. If I look at the processes running I have one for the server start and another for the ping which seems hung.

If I try to ping the server it just hangs with:
"main" prio=6 tid=0x00297800 nid=0x1eb0 runnable [0x0090f000..0x0090fe54]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:129)
        at java.net.SocketInputStream.read(SocketInputStream.java:90)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(NetworkServerControlImpl.java:2565)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(NetworkServerControlImpl.java:2509)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(NetworkServerControlImpl.java:995)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(NetworkServerControlImpl.java:972)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:1959)
        at org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:284)

I also get a hang if I try to connect with ij, so the server seems to have stopped accepting connections.

The server is running in a separate process so I don't know how on windows to get a thread dump for that process. I've attached the patch derby-3708_10.3_nocommit.txt. Any thoughts on how to debug this are welcome.

[Kathey Marsden]

I think I need part of the fix for DERBY-3504 which fixed the potential for server hang. One thing I notice is if I abort the test and the server process is left running I can then ping or shutdown the server. So that lends itself to it being a problem with processing the output from the process (DERBY-3504). It doesn't look like a clean merge though. I think I also need some other intervening change.

[Kathey Marsden]

I think for the 10.3 fix I will backport the code change but not the test change and just test manually. I looked into what it would take to backport the changes to get the spawned process to work properly and not hang and it looked tangled up with other changes and difficult to backport. Please let me know if this does not seem acceptable.