Shareable executors

[mikkokar]

Summary

This PR allows end users to declare named executors (or threads) and share them between different Styx objects.

The executors only work with the new HostProxy and HttpServer objects. The old proxy and admin servers, and the old Styx Client, which are being phased out, still use the old clientWorkerThreadsCount, workerThreadsCount, and bossThreadsCount settings.

Configuration

The executors are declared in the executors block at the top-level of Styx configuration file:

executors:
  server:
    type: NettyExecutor
    config:
      threads: 4
      namePattern: "Styx-Server-Worker" 

The executor can be shared by other objects:

routing:
  originA:
    type: HostProxy
    config:
        ...
        executor: "server"

servers:
  https:
    type: HttpServer:
    config:
        ...
        executor: "server"

The top level yaml configuration follows the schema:

optional("executors", map(routingObject())),

Where routingObject is the familiar type/config/tags triple. The NettyExecutor object follows the schema:

    val SCHEMA = SchemaDsl.`object`(
            SchemaDsl.field("threads", SchemaDsl.integer()),
            SchemaDsl.field("namePattern", SchemaDsl.string())
    )

Styx is started with 3 "global" executors:

• Styx-Client-Global-Worker, StyxHttpServer-Global-Worker, StyxHttpServer-Global-Boss. The routing objects will use them unless some other are specified by executor field. Consequently these names are reserved. Styx will always make sure that default global executors are available.

• You can override the default global executor settings by specifying that reserved name in the executor configuration. For example, the following configuration will change the thread names for global server worker thread:

executors:
  StyxHttpServer-Global-Worker:
    type: NettyExecutor
    config:
      threads: 4
      namePattern: "styx-worker" 

Add a new executor field to YamlFileConfigurationService configuration. To specify the executor for the created HostProxy objects. When executor field is absent, it should use the default global executor.

[dvlato]

Should we wait here?

[mikkokar]

Hi. It does wait for shutdownGracefully to come back.

Or do you refer to the quietPeriod setting? But we never really supported a graceful shutdown properly. Yet. I think we need to implement that on a "styx level".

The reason for immediate quiet and grace period is to avoid excessive waiting in functional test suite.

However I do think, going forward, we need to add timeout controls and a shutdown future to this API. Perhaps that should be a next increment, providing that the work is completed before the Styx 1.1 release. WDYT?

[mikkokar]

The executors will only ever be closed when styx shuts. Therefore any shutdown future, etc doesn't really matter at the moment as the JVM is going to shut anyway. I would revisit this code if or once we'll allow consumers to shut injected executors.

[dvlato]

This is clearing the interrupted flag, we've discussed previously it might not be the best option.

[mikkokar]

Thanks. A good catch :-)

[mikkokar]

Fixed.

[dvlato]

Should we try not to not pass a JsonNode here? It seems we keep propagating our Yaml based config.

[mikkokar]

This code follows the idiomatic fashion of creating styx objects from yaml/json nodes. Sadly the styx object model relies entirely on yaml and/or JsonNode based configuration.

I have created a a proof of concept that lifts this restriction. Check the details in PR: #609 (Remove old application router).

Till then, it needs to stay in this "idiomatic" form.

[dvlato]

This could throw several exceptions here... makes me think we might want to implement Autocloseable.

[mikkokar]

You mean, for the StyxService?

[chrisgresty]

Just a couple of minor suggestiions.