Interaction of security manager with DRDA tracing -- is this bug?

[Bryan Pendleton <bp...@amberpoint.com>]

I was trying to enable server-side DRDA tracing while running
a particular test by hand. I tweaked procedure_derby.properties
to add

derby.drda.traceAll=true
derby.drda.traceDirectory=/some/directory

I created /some/directory and then ran my test, only to see
it *hang*. I used kill -QUIT to get a stack trace from my
test and am including that information below.

I guess what I'm trying to figure out here is: it seems that
when the DRDA tracing fails with a security exception, some
bit of Network Server session initialization fails and instead
of getting a clear error, I get a hang instead.

Is this a bug? Or is this just the way it works?

BTW, what is the best/easiest way to turn on such tracing
while running a particular test; I seem to be stomping and
pawing at the ground and not having terribly much success...

thanks,

bryan

-bash-2.05b$ cat ./DerbyNetClient/procedure/DerbyNetClient.out
Server is ready to accept connections on port 1527.
access denied (java.io.FilePermission /home/bpendleton/src/derby/jira-614/test_proc/serverTraces/Server1.trace write)
java.security.AccessControlException: access denied (java.io.FilePermission 
/home/bpendleton/src/derby/jira-614/test_proc/serverTraces/Server1.trace write)
         at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
         at java.security.AccessController.checkPermission(AccessController.java:401)
         at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
         at java.lang.SecurityManager.checkWrite(SecurityManager.java:954)
         at java.io.FileOutputStream.<init>(FileOutputStream.java:169)
         at java.io.FileOutputStream.<init>(FileOutputStream.java:70)
         at java.io.FileWriter.<init>(FileWriter.java:46)
         at org.apache.derby.impl.drda.DssTrace.startComBufferTrace(DssTrace.java:169)
         at org.apache.derby.impl.drda.Session.initTrace(Session.java:136)
         at org.apache.derby.impl.drda.Session.initialize(Session.java:256)
         at org.apache.derby.impl.drda.Session.<init>(Session.java:93)
         at org.apache.derby.impl.drda.ClientThread.run(ClientThread.java:90)
         at java.lang.Thread.run(Thread.java:534)
Full thread dump Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode):

"Thread-2" prio=1 tid=0x0835a800 nid=0x7e89 runnable [a988d000..a988d87c]
         at java.net.PlainSocketImpl.socketAccept(Native Method)
         at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353)
         - locked <0xaaf478b8> (a java.net.PlainSocketImpl)
         at java.net.ServerSocket.implAccept(ServerSocket.java:448)
         at java.net.ServerSocket.accept(ServerSocket.java:419)
         at org.apache.derby.impl.drda.ClientThread$1.run(ClientThread.java:64)
         at java.security.AccessController.doPrivileged(Native Method)
         at org.apache.derby.impl.drda.ClientThread.run(ClientThread.java:60)
         at java.lang.Thread.run(Thread.java:534)

"Thread-0" daemon prio=1 tid=0x083a30d0 nid=0x7e89 in Object.wait() [a990e000..a990e87c]
         at java.lang.Object.wait(Native Method)
         - waiting on <0xaaf40050> (a java.util.TaskQueue)
         at java.lang.Object.wait(Object.java:429)
         at java.util.TimerThread.mainLoop(Timer.java:403)
         - locked <0xaaf40050> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:382)

"derby.antiGC" daemon prio=1 tid=0x08373248 nid=0x7e89 in Object.wait() [a998f000..a998f87c]
         at java.lang.Object.wait(Native Method)
         - waiting on <0xab3f3490> (a org.apache.derby.impl.services.monitor.AntiGC)
         at java.lang.Object.wait(Object.java:429)
         at org.apache.derby.impl.services.monitor.AntiGC.run(BaseMonitor.java:2204)
         - locked <0xab3f3490> (a org.apache.derby.impl.services.monitor.AntiGC)
         at java.lang.Thread.run(Thread.java:534)

"Signal Dispatcher" daemon prio=1 tid=0x080a77f8 nid=0x7e89 waiting on condition [0..0]

"Finalizer" daemon prio=1 tid=0x08092b08 nid=0x7e89 in Object.wait() [aad3d000..aad3d87c]
         at java.lang.Object.wait(Native Method)
         - waiting on <0xab3ac8c8> (a java.lang.ref.ReferenceQueue$Lock)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
         - locked <0xab3ac8c8> (a java.lang.ref.ReferenceQueue$Lock)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=1 tid=0x08091f60 nid=0x7e89 in Object.wait() [aadbe000..aadbe87c]
         at java.lang.Object.wait(Native Method)
         - waiting on <0xab3ac930> (a java.lang.ref.Reference$Lock)
         at java.lang.Object.wait(Object.java:429)
         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115)
         - locked <0xab3ac930> (a java.lang.ref.Reference$Lock)

"main" prio=1 tid=0x0805c788 nid=0x7e89 in Object.wait() [bfffb000..bfffb968]
         at java.lang.Object.wait(Native Method)
         - waiting on <0xab3c2d88> (a java.lang.Object)
         at java.lang.Object.wait(Object.java:429)
         at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(NetworkServerControlImpl.java:575)
         - locked <0xab3c2d88> (a java.lang.Object)
         at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:1699)
         at org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:238)

"VM Thread" prio=1 tid=0x08090d00 nid=0x7e89 runnable

"VM Periodic Task Thread" prio=1 tid=0x080a9fb0 nid=0x7e89 waiting on condition
"Suspend Checker Thread" prio=1 tid=0x080a6ca0 nid=0x7e89 runnable

Re: Interaction of security manager with DRDA tracing -- is this bug?

[Deepa Remesh <dr...@gmail.com>]

On 12/24/05, Bryan Pendleton <bp...@amberpoint.com> wrote:
> I was trying to enable server-side DRDA tracing while running
> a particular test by hand. I tweaked procedure_derby.properties
> to add
>
> derby.drda.traceAll=true
> derby.drda.traceDirectory=/some/directory
>
> I created /some/directory and then ran my test, only to see
> it *hang*. I used kill -QUIT to get a stack trace from my
> test and am including that information below.
>
> I guess what I'm trying to figure out here is: it seems that
> when the DRDA tracing fails with a security exception, some
> bit of Network Server session initialization fails and instead
> of getting a clear error, I get a hang instead.
>
> Is this a bug? Or is this just the way it works?

I too expect a clear error from network server instead of a hang.
Maybe you can open a JIRA issue for this.

>
> BTW, what is the best/easiest way to turn on such tracing
> while running a particular test; I seem to be stomping and
> pawing at the ground and not having terribly much success...
>

The security permissions used by tests are in
org.apache.derbyTesting.functionTests.util.derby_tests.policy file. If
you need write permission to some other directory for your test, you
will have to add the permission to this file. It is recommended to
keep the permissions in this file to a minimal set. But it is good to
have permissions for a particular directory for tracing. Dan explains
this is in detail in this thread:
http://www.nabble.com/-Fwd%3A-Re%3A-derbynet-getCurrentProperties.java-fails--t417532.html#a1144951

Hope this helps.

Thanks,
Deepa