Skip to content

Single Process Modules

Jump to bottom
Paul Rogers edited this page Dec 2, 2021 · 4 revisions

This page discusses the Druid inventory of Druid modules and which behavior must change to support a Single Process Druid.

Startup Modules

  • DruidGuiceExtensions: binds the Druid scope Singleton to the LazySingleton annotation.
  • JacksonModule: Startup-time Jackson resources. (Replaced later in DruidSecondaryModule).
  • PropertiesModule: Loads property files from the class path. See Property Files.
  • RuntimeInfoModule
  • ConfigModule
  • NullHandlingModule
  • ExpressionProcessingModule
  • Inline module which seems to define the DruidSecondaryModule (?).

Default (Common) Modules

  • Log4jShutterDownerModule: shuts down the global Log4j service.
  • DruidAuthModule: Binds authorization configuration.
  • LifecycleModule: "Adds lifecycle management to the injector". See Lifecycle.
  • TLSCertificateCheckerModule: TLS configuration.
  • EmitterModule: Sets up the logging emitter (output).
  • HttpClientModule: The HTTP client used to communicate with other nodes.
  • CuratorModule: manages the ZK Curator client for the server.
  • AnnouncerModule: "announces things using ZK".
  • MetricsModule: System-level (JVM, CPU) monitoring.
  • SegmentWriteOutMediumModule: Defines the "segment write-out" factory.
  • ServerModule: Config objects for the DruidNode and for ZK. The singleton DruidNode assumes one service and port per server.
  • DruidProcessingConfigModule: Creates an instance of DruidProcessingConfig using Config Magic from the set of Properties. The actual processing module is created per-service.
  • StorageNodeModule: Configures the kind of segment support for the node. Defaults to null. Services must override it with a service-specificServerType. This is a singleton, and conflicts for a shared server.
  • JettyServerModule: Configures the Jetty server. See Web Apps.
  • ExpressionModule: Adds a set of expression "macros". Seems to have no dependencies: candidate for a base injector.
  • DiscoveryModule: Handles "registration of Keys of DruidNode objects, which it intends to be automatically announced at the end of the lifecycle start." Depends on ZK.
  • ServerViewModule: List of available servers? No dependencies.
  • MetadataConfigModule: Loads configuration for several metadata items. Depends on properties.
  • DerbyMetadataStorageDruidModule: Derby metadata storage. Overridden by another module if another DB is used?
  • JacksonConfigManagerModule: Configuration for the polling interval. Depends on the lifecycle.
  • IndexingServiceDiscoveryModule: Discovery of the lead indexer. Depends on the escalated HTTP client.
  • CoordinatorDiscoveryModule: As above, but for the coordinator.
  • LocalDataStorageDruidModule: Default local storage module.
  • FirehoseModule: Defines "firehose"(?) Jackson types.
  • JavaScriptModule: Defines Javascript support. No dependencies.
  • AuthenticatorModule: Default permissive authenticator?
  • AuthenticatorMapperModule: Builds the list of authenticators from the AuthConfig.
  • EscalatorModule: Defines one class. No dependencies.
  • AuthorizerModule: Defines the "allow all" authorizer?
  • AuthorizerMapperModule: Builds the list of authorizors. Similar to AuthenticatorMapperModule
  • StartupLoggingModule: Configures the startup logger.
  • ExternalStorageAccessSecurityModule: Configures JDBC credentials. (For metadata?)
  • DruidSecondaryModule: Copies or rewrites selected startup resources into the service injector.

Several modules that have no dependencies and could be candidates for a base injector. However, we can't be sure that extensions don't replace some of these modules.

Any module that depends on the Lifecycle adds bindings and thus must occur in the leaf-most injector. This, alone, suggests that it is not helpful to have an intermediate injector.

Coordinator Modules

Overlord Modules

Overrides

Inspection of the module lists shows that, in a "stock" Druid, running the Broker, there are no actual resource overrides among the standard and extension modules. Any duplicate keys are due to multi-bindings and poly-bindings.

Discussion with developers suggests that extensions should only either 1) add to a multi- or poly-binding, or 2) and their own keys. Though the code allows an extension to replace a key defined by the standard code, doing so is not actually supported and behavior is undefined. (The team wants to allow such overrides, but does not want to test or support them, resulting in a rather hazy set of guidelines.)

Clone this wiki locally