[ 
http://issues.apache.org/jira/browse/DERBY-395?page=comments#action_12364291 ] 

Bryan Pendleton commented on DERBY-395:
---------------------------------------

I believe that the issue here is that ClientThread.java was mistakenly 
maintaining its own private cache of the values of the 
derby.drda.traceDirectory and derby.drda.traceAll settings. The 
NetworkServerControl commands are properly changing the master values in 
NetworkServerControlImpl, but since ClientThread.java never re-fetched the 
updated values, the updates didn't seem to "take".

I don't see any reason why ClientThread.java needs to maintain its own cache of 
these values, so I think the following change should do the trick. I've 
successfully tested the bug scenarios using this change and they seem to work 
well; I'm running derbyall just in case, though I don't think it touches any of 
these code paths. Assuming it runs clean, I'll attach the diff to this issue.

Index: java/drda/org/apache/derby/impl/drda/ClientThread.java
===================================================================
--- java/drda/org/apache/derby/impl/drda/ClientThread.java      (revision 
373059)
+++ java/drda/org/apache/derby/impl/drda/ClientThread.java      (working copy)
@@ -30,8 +30,6 @@
        ServerSocket serverSocket;
        private int timeSlice;
        private int connNum;
-       private String traceDir;
-       private boolean traceAll;

                ClientThread (NetworkServerControlImpl nsi, ServerSocket ss) {

@@ -42,8 +40,6 @@
                        parent=nsi;
                        serverSocket=ss;
                        timeSlice=nsi.getTimeSlice();
-                       traceDir=parent.getTraceDirectory();
-                       traceAll=parent.getTraceAll();
                }

                public void run()
@@ -88,7 +84,8 @@

                                //create a new Session for this session
                                clientSession = new Session(connNum, 
clientSocket,
-                                       traceDir, traceAll);
+                                       parent.getTraceDirectory(),
+                                       parent.getTraceAll());

                                //add to Session list
                                parent.addToSessionTable(new Integer(connNum), 
clientSession);


> Server-side "trace on" and "trace off" commands do not appear to be working 
> correctly.
> --------------------------------------------------------------------------------------
>
>          Key: DERBY-395
>          URL: http://issues.apache.org/jira/browse/DERBY-395
>      Project: Derby
>         Type: Bug
>   Components: Network Server
>     Versions: 10.1.1.0, 10.0.2.2
>  Environment: Running Derby Network Server with either JCC or Derby client.
>     Reporter: A B
>     Assignee: Bryan Pendleton
>      Fix For: 10.2.0.0

>
> Documentation in the Server & Admin guide talks about a "derby.drda.traceAll" 
> system property and two trace commands available from the 
> NetworkServerControl API: "trace on" and "trace off".   The "trace on" 
> command is supposed to turn tracing on for all server sessions, unless a 
> specific session number is passed in via the "-s" parameter.  Similarly, the 
> "trace off" command is supposed to turn tracing off for all server sessions, 
> unless a specific session number is passed in via the "-s" parameter.
> However, I've noticed the following behavior, which appears to be incorrect.
> 1) if the server is started with derby.drda.traceAll=true, then subsequent 
> attempts to turn tracing off do not work.  For example:
> // Start the server with 'traceAll' set to true.
> > java -Dderby.drda.traceAll=true org.apache.derby.drda.NetworkServerControl 
> > start
> Server is ready to accept connections on port 1527.
> // Try to turn tracing off.
> > java org.apache.derby.drda.NetworkServerControl trace off
> Trace turned off for all sessions.
> But then, despite the message saying that trace was turned off, tracing is 
> still enabled for all connections thereafter: if I connect three more times, 
> I will see a 'ServerX.trace' file for each connection.
> 2) If the server is started with derby.drda.traceAll=false, then attempts to 
> turn tracing on _only_ affect the connection that enables tracing; tracing 
> will NOT be done for any subsequent connections.  For ex:
> // Start the server with 'traceAll' set to false (which is also the default)
> > java -Dderby.drda.traceAll=false org.apache.derby.drda.NetworkServerControl 
> > start
> Server is ready to accept connections on port 1527.
> // Turn tracing on.
> > java org.apache.derby.drda.NetworkServerControl trace on
> Trace turned on for all sessions.
> Now I see a 'ServerX.trace' for the connection that was made to turn tracing 
> on.  However, if I then connect three more times, I will _not_ see any 
> 'ServerX.trace' files for those connections.

-- 
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

Reply via email to