Specification of incomplete server properties on command line causes NPE with NetworkServerControl when starting the server.

• Key: DERBY-375
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Deepa Remesh
• Reporter: A B
• Component/s: Network Server
• Affects Version/s: 10.1.1.0, 10.2.1.6
• Fix Version/s: 10.1.2.1, 10.2.1.6

Description

When using the command line to start the Network Server, there a couple of cases where if a property is specified on the command line but no value is given (ex. "-Dderby.drda.maxThreads" instead of "-Dderby.drda.maxThreads=3"), a Null Pointer Exception will result, when the correct behavior should be to use some kind of default.

For example:

> java -Dderby.drda.maxThreads org.apache.derby.drda.NetworkServerControl start -p 1528
java.lang.NullPointerException
        at org.apache.derby.impl.drda.NetworkServerControlImpl.localizeMessage(NetworkServerControlImpl.java)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.consolePropertyMessageWork(NetworkServerControlImpl.java)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.consolePropertyMessage(NetworkServerControlImpl.java)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.getIntPropVal(NetworkServerControlImpl.java)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.getPropertyInfo(NetworkServerControlImpl.java)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.<init>(NetworkServerControlImpl.java)
        at org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java)

Note that even though we see this NPE, it appears that the server still starts up, although the startup may not be complete (subsequent attempts to connect might lead to errors like "Invalid reply from network server: Insufficient data.").

For other properties, this will just result in the default value being used, which is the correct behavior. For example:

> java -Dderby.drda.host org.apache.derby.drda.NetworkServerControl start -p 1528
Server is ready to accept connections on port 1528.

Comments

Moving to 10.2

[Deepa Remesh]

The default values for network server properties mentioned in Derby Server and Administration Guide are:

derby.drda.host - If no host name is specified, the Network Server listens on the loopback address of the current machine (localhost).
derby.drda.keepAlive - true
derby.drda.logConnections - false
derby.drda.maxThreads - 1
derby.drda.minThreads - 1
derby.drda.portNumber - If no port number is specified, 1527 is the default.
derby.drda.startNetworkServer - false
derby.drda.timeSlice - 1
derby.drda.traceAll - false
derby.drda.traceDirectory - If the derby.system.home property has been set, it is the default. Otherwise, the default is the current directory.
derby.drda.debug - false

However, in the code, default value of minThreads, maxThreads and timeSlice is '0'. In my patch too, I am using '0' as the default value for these. I also saw a test (maxThread.java) which tests default value of maxThreads as '0'. I think the document needs to be updated. Also, the property 'derby.drda.debug' is not listed in the admin guide. Is this an internal property not exposed to users?

[Deepa Remesh]

Attaching a patch 'derby-375.diff' for this problem. Network server was giving NPE when system properties were specified without values. When a system property is specified without any value, the getProperty method in java.util.Properties returns an empty string. For the following network server properties (minThreads, maxThreads, timeSlice and portNumber), 'getPropertyInfo' method in NetworkServerControlImpl will pass this empty string to 'getIntPropVal'. This will try to get the Integer value and will cause an exception. To display this exception, 'localizeMessage' method is used. At this point, 'langUtil' which is passed to 'localizeMessage' is not yet initialized and this results in the NPE.

The patch does the following:
1. Moves the call to 'init', which initializes 'langUtil', before the call to 'getPropertyInfo' method in the constructors of NetworkServerControlImpl.
2. If the system properties are specified without values, use defaults for them.
3. For 'derby.drda.traceDirectory' property following is mentioned in the doc - "If the derby.system.home property has been set, it is the default. Otherwise, the default is the current directory.". 'getPropertyInfo' was getting the value of 'derby.system.home' but not using it as default for 'derby.drda.traceDirectory'.
So the current directory was always getting used as default. Changed this.
4. When I added the default for 'derby.drda.traceDirectory', the tests derbynet/getCurrentProperties.java and derbynet/sysinfo.java had additional lines for derby.drda.traceDirectory in their outputs. Since the directory listed is dependent on the test directory, I have sed out 'traceDirectory' lines for these tests.
5. Adds tests to derbynet/testProperties.java.
6. Fixes javadoc for 'traceDirectory' in NetworkServerControl.

Ran derbyall on Windows XP with Sun jdk 1.4.2. 1 test failed (derbyall/derbyall.fail:lang/ConcurrentImplicitCreateSchema.java). The failure is not related to this change.

This patch also fixes DERBY-613 (Intended location of network server tracing files is not clear.). Please review/commit this patch. I'll open a sub-task to update documentation with the correct default values for maxThreads, minThreads and timeSlice.

[Kathey Marsden]

Reviewed and committed this patch to the trunk. Looks good. Thanks for fixing DERBY-613 too!
My only comment would be that perhaps it would be better to use a substitute to something generic rather than a delete of the traceDirectory lines. If you feel so motivated you could submit a followon patch.

Date: Fri Oct 14 18:22:15 2005
New Revision: 321274

URL: http://svn.apache.org/viewcvs?rev=321274&view=rev

[A B]

The patch for this has been committed and I verified that the example shown in this description now works against the trunk, as do the new test cases in derbynet/testProperties. Should this fix be ported to 10.1? The Fix version is only specified as 10.2.0.0, so if that's correct, I'll go ahead and resolve/close this issue...

[Deepa Remesh]

Thanks for verifying. I was not planning to merge this to 10.1. You may close this issue.

[A B]

Patch was reviewed and applied to trunk with svn 321274. I verified that the issue has been fixed in the trunk, so I am now resolving and closing this issue.

[Deepa Remesh]

Re-opening to merge fix to 10.1

[Deepa Remesh]

I merged this fix to my 10.1 codeline and ran derbyall with Sun JDK 1.4.2 on Windows XP. 2 failures:
derbyall/derbyall.fail:unit/T_Diagnosticable.unit (This test passed when I re-ran it)
derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql (master update issue)

Merge command:
svn merge -r 321273:321274 https://svn.apache.org/repos/asf/db/derby/code/trunk
svn merge -r 326288:326289 https://svn.apache.org/repos/asf/db/derby/code/trunk

Please merge this to 10.1 branch. Thanks.

[Kathey Marsden]

Checked this fix which also fixes DERBY-613 into 10.1

Date: Thu Oct 20 15:39:09 2005
New Revision: 327018

URL: http://svn.apache.org/viewcvs?rev=327018&view=rev

[Deepa Remesh]

Verified in 10.1 by running the example in description.