Add scan server prefix to valid zooProp list

[ddanielr]

Adds the scan server properties prefix to the list of valid zooProps.
This allows the scan server properties to be modified via the shell.

[dlmarion]

No issue with this change. However, I think Property.fixedProperties needs to be reviewed. There are properties that we are marking as mutable by using the prefix property that require a restart, but are not in the fixedProperties set. For example, tserver.server.threads.minimum is marked mutable, so it can be changed in ZK, but the TServer will not update it's internal value and restart the Thrift Server.

[ddanielr]

No issue with this change. However, I think Property.fixedProperties needs to be reviewed. There are properties that we are marking as mutable by using the prefix property that require a restart, but are not in the fixedProperties set. For example, tserver.server.threads.minimum is marked mutable, so it can be changed in ZK, but the TServer will not update it's internal value and restart the Thrift Server.

Looking at this, should all the properties that are used as arguments to TServerUtils.startServer be considered fixed?

accumulo/server/base/src/main/java/org/apache/accumulo/server/rpc/TServerUtils.java

Lines 131 to 135 in 361ed50

	public static ServerAddress startServer(ServerContext context, String hostname,
	Property portHintProperty, TProcessor processor, String serverName, String threadName,
	Property portSearchProperty, Property minThreadProperty, Property threadTimeOutProperty,
	Property timeBetweenThreadChecksProperty, Property maxMessageSizeProperty)
	throws UnknownHostException {

If so I can make updates to Property.fixedProperties for the various missing properties.

[dlmarion]

Looking at this, should all the properties that are used as arguments to TServerUtils.startServer be considered fixed?

Most likely. Also, the cache properties are likely also fixed. The code would need to be evaluated to determine if a running server will respect property changes. Being ZK mutable allows the user to change the property in the shell. It will take effect for servers started after the change, but there is no guarantee that running servers will be updated.

[dlmarion]

@ddanielr - I looked through the ScanServer code. These need to be added to the fixedProperties. The only properties that are checked at runtime are the ones dealing with the scan executors.

      // sserver fixed properties
      SSERV_CACHED_TABLET_METADATA_EXPIRATION, SSERV_PORTSEARCH, SSERV_DATACACHE_SIZE,
      SSERV_INDEXCACHE_SIZE, SSERV_SUMMARYCACHE_SIZE, SSERV_DEFAULT_BLOCKSIZE,
      SSERVER_SCAN_REFERENCE_EXPIRATION_TIME, SSERV_CLIENTPORT, SSERV_MAX_MESSAGE_SIZE,
      SSERV_MINTHREADS, SSERV_MINTHREADS_TIMEOUT, SSERV_THREADCHECK,

[ddanielr]

@ddanielr - I looked through the ScanServer code. These need to be added to the fixedProperties. The only properties that are checked at runtime are the ones dealing with the scan executors.

      // sserver fixed properties
      SSERV_CACHED_TABLET_METADATA_EXPIRATION, SSERV_PORTSEARCH, SSERV_DATACACHE_SIZE,
      SSERV_INDEXCACHE_SIZE, SSERV_SUMMARYCACHE_SIZE, SSERV_DEFAULT_BLOCKSIZE,
      SSERVER_SCAN_REFERENCE_EXPIRATION_TIME, SSERV_CLIENTPORT, SSERV_MAX_MESSAGE_SIZE,
      SSERV_MINTHREADS, SSERV_MINTHREADS_TIMEOUT, SSERV_THREADCHECK,

I took that list and also expanded it to include those properties under any other server types.

[dlmarion]

I think this is good. There are likely many others that are fixed, but that can be done in a different PR.

[ctubbsii]

It would be nice to have an extra attribute on each property that denoted these attributes, so we didn't have to maintain a separate list. I'm not sure that would be a huge improvement, but it might make it easier to keep up-to-date because we'd have to consciously think about these attributes when we create or modify properties, rather than having to add them to a separate hard-coded list somewhere else when they need to be updated.