You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "A B (JIRA)" <de...@db.apache.org> on 2005/06/28 02:34:57 UTC
[jira] Created: (DERBY-395) Server-side "trace on" and "trace off" commands do not appear to be working correctly.
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.0.2.2, 10.1.1.0
Environment: Running Derby Network Server with either JCC or Derby client.
Reporter: A B
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
[jira] Commented: (DERBY-395) Server-side "trace on" and "trace
off" commands do not appear to be working correctly.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Commented: (DERBY-395) Server-side "trace on" and "trace
off" commands do not appear to be working correctly.
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-395?page=comments#action_12364362 ]
Kathey Marsden commented on DERBY-395:
--------------------------------------
Verified manually that bug ws fixed and checked in.
Date: Sat Jan 28 21:54:06 2006
New Revision: 373291
URL: http://svn.apache.org/viewcvs?rev=373291&view=rev
> 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
> Attachments: svn.status, svn_jan_27_2006.diff
>
> 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
[jira] Updated: (DERBY-395) Server-side "trace on" and "trace off"
commands do not appear to be working correctly.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-395?page=all ]
Bryan Pendleton updated DERBY-395:
----------------------------------
Attachment: svn_jan_27_2006.diff
svn.status
Attached is a proposed fix. derbyall passed. I put a small comment in the code. I didn't add any new tests, which is unfortunate, but I didn't have any brilliant inside about an easy way to add such tests. Testing with the server tracing is already somewhat of a PITA because the server tracing interacts poorly with things like the security manager. Suggestions for clean ways to add some tests here would be appreciated.
This is a very low priority bug, but if a committer has some time to check it, that would be great. The repro instructions in the bug description are very clear; it's just a matter of verifying that you can reproduce the problem without the patch, then verifying that the patch resolves the problem for you.
> 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
> Attachments: svn.status, svn_jan_27_2006.diff
>
> 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
[jira] Closed: (DERBY-395) Server-side "trace on" and "trace off"
commands do not appear to be working correctly.
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-395?page=all ]
A B closed DERBY-395:
---------------------
Verified fix manually and it has been ported to 10.1. So I'm marking it closed.
> 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, 10.1.3.0, 10.1.2.4
> Attachments: svn.status, svn_jan_27_2006.diff
>
> 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
[jira] Resolved: (DERBY-395) Server-side "trace on" and "trace off"
commands do not appear to be working correctly.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-395?page=all ]
Bryan Pendleton resolved DERBY-395:
-----------------------------------
Fix Version: 10.1.3.0
10.1.2.4
Resolution: Fixed
Merged the fix from the trunk to the 10.1 branch. The merge was clean and the testing was successful.
The change is in revision 398382:
http://svn.apache.org/viewcvs?rev=398382&view=rev
> 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, 10.1.3.0, 10.1.2.4
> Attachments: svn.status, svn_jan_27_2006.diff
>
> 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
[jira] Assigned: (DERBY-395) Server-side "trace on" and "trace off"
commands do not appear to be working correctly.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-395?page=all ]
Bryan Pendleton reassigned DERBY-395:
-------------------------------------
Assign To: Bryan Pendleton
> 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
[jira] Commented: (DERBY-395) Server-side "trace on" and "trace
off" commands do not appear to be working correctly.
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-395?page=comments#action_12364322 ]
Kathey Marsden commented on DERBY-395:
--------------------------------------
Thanks Bryan,
I'll look into committing this patch
> 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
> Attachments: svn.status, svn_jan_27_2006.diff
>
> 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
[jira] Reopened: (DERBY-395) Server-side "trace on" and "trace off"
commands do not appear to be working correctly.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-395?page=all ]
Bryan Pendleton reopened DERBY-395:
-----------------------------------
Reopening to merge fix to 10.1
> 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
> Attachments: svn.status, svn_jan_27_2006.diff
>
> 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
[jira] Resolved: (DERBY-395) Server-side "trace on" and "trace off"
commands do not appear to be working correctly.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-395?page=all ]
Bryan Pendleton resolved DERBY-395:
-----------------------------------
Resolution: Fixed
> 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
> Attachments: svn.status, svn_jan_27_2006.diff
>
> 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