ctubbsii commented on a change in pull request #2143:
URL: https://github.com/apache/accumulo/pull/2143#discussion_r645093001
##########
File path: core/src/main/java/org/apache/accumulo/core/conf/Property.java
##########
@@ -1045,40 +1045,44 @@
"The maximum size of a message that can be sent to a tablet server."),
// CompactionCoordinator properties
@Experimental
- COORDINATOR_PREFIX("coordinator.", null, PropertyType.PREFIX,
+ COMPACTION_COORDINATOR_PREFIX("compaction_coordinator.", null,
PropertyType.PREFIX,
Review comment:
> I am under the impression (maybe mistakenly) that the first part of
the property name for processes should be the process name (`manager`, `gc`,
`tserver`, `monitor`, etc).
Roughly speaking, properties are organized that way, but we also have other
prefixes `rpc`, `instance`, `general`, `table`, and `replication. For these, I
sort of see the compaction coordinator and the compactors as part of a single
external system (prefix `compaction`) with two sub-components of that
externalized system that are servers (performing the roles of `coordinator` and
`worker`).
The important part isn't that the first part be a server type, but that
properties are organized so they can be scoped to a particular component. In
other words, we can exclude all `table.*`, and `gc.*` if we're starting a
tserver. In theory, configuration could even be spread across different config
files (as in `bin/accumulo tserver --config /path/to/tserver.conf`, where
`tserver.conf` contains some `include = instance.props` directive and a bunch
of `tserver.<prop> = <value>` lines). So, organization is important to support
various configuration management use cases, but having the first element be a
server type isn't specifically important.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
