services.xml - container

This is the reference for container cluster configuration:

container [version, id]
    http
        server [id, port]
        filtering
    handler [id, class, bundle]
        binding
        component
    server [id, class, bundle]
    components
    component
    search
        include [dir]
        binding
        searcher
        federation
        provider
        chain
        renderer
        threadpool
        significance
    document-processing
        include [dir]
        documentprocessor
        chain
    processing
        include [dir]
        binding
        processor
        chain
        renderer
    document-api
        abortondocumenterror
        retryenabled
        route
        maxpendingdocs
        maxpendingbytes
        retrydelay
        timeout
        tracelevel
        mbusport
        ignore-undefined-fields
    model-evaluation
        onnx
    document [type, class, bundle]
    accesslog [type, fileNamePattern, symlinkName, rotationInterval, rotationScheme]
    config
    nodes [allocated-memory, jvm-gc-options, jvm-options]
        environment-variables
        jvm [allocated-memory, options, gc-options]
        node [hostalias]
    secret-store [type]
        group [name, environment]
    zookeeper

Contained in services, zero or more container elements. The root element of a container cluster definition. Most elements takes optional config elements.

Example:

<container id="default" version="1.0">
    <search>
        <chain id="default">
            <searcher id="com.mydomain.SimpleSearcher" bundle="the name in <artifactId> in pom.xml"/>
        </chain>
    </search>
    <nodes>
        <node hostalias="node1"/>
    </nodes>
</container>

Each container cluster has a default http server port, unless it contains a http element. Hence, when running more than one container cluster on the same node, it is necessary to manually assign a port to the http server to all but one cluster. Otherwise, the application will not deploy. Assigning a port is done by adding a server element with an explicit port number:

<container id="cluster2" version="1.0">
    <http>
        <server id="myServer" port="8081" />
    </http>
    ...
</container>

handler

The handler element holds the configuration of a request handler. For each binding tag, the handler will be bound to the pertinent JDisc interfaces using the given binding.

• binding For JDisc request handlers, add this server binding to this handler.
• component for injecting another component. Must be a declaration of a new component, not a reference.

Example:

<container id="default" version="1.0">
    <handler id="com.yahoo.search.handler.LegacyBridge">
        <binding>http://*/*</binding>
    </handler>
    <handler bundle="the name in <artifactId> in pom.xml" id="com.mydomain.vespatest.RedirectingHandler"/>
    <handler bundle="the name in <artifactId> in pom.xml" id="com.mydomain.vespatest.ExampleHandler"/>
    <nodes>
        <node hostalias="node1"/>
    </nodes>
</container>

binding

The URI to map a Handler to. Multiple elements are allowed. See example above.

server

The server element holds the configuration of a JDisc server provider.

<server id="com.mydomain.vespatest.DemoServer">
    <config name="vespatest.demo-server">
        <response>Hello, world!
        </response>
        <port>16889</port>
    </config>
</server>

components

Contains component elements. Can be used in conjunction with include for modular config of components.

component

The component element holds the configuration of a generic component. Must be a declaration of a new component, not a reference.

Nested component child elements can be added for injecting specific component instances. This is useful if there is more than one declared component of the same Java class. Refer to Injecting components for details and examples.

Example:

<component id="com.mydomain.demo.DemoComponent" bundle="the name in <artifactId> in pom.xml" />

document-api

Use to enable Document API operations to a container cluster. Children elements:

<document-api>
    <binding>http://*/document-api/</binding>
    <binding>https://*/document-api/</binding>
</document-api>

Example:

<document-api>
    <binding>http://*/document-api/</binding>
    <binding>https://*/document-api/</binding>
    <abortondocumenterror>false</abortondocumenterror>
    <maxpendingbytes>1048576</maxpendingbytes>
    <maxpendingdocs>1000</maxpendingdocs>
    <mbusport>1234</mbusport>
    <retrydelay>5.5</retrydelay>
    <retryenabled>false</retryenabled>
    <route>default</route>
    <timeout>250.5</timeout>
    <tracelevel>3</tracelevel>
<document-api>

document

Concrete document type bindings for the container. Example:

<container id="default" version="1.0">
    <document class="com.mydomain.concretedocs.Vehicle"
              bundle="the name in <artifactId> in pom.xml"
              type="vehicle"/>
    <document class="com.mydomain.concretedocs.Vehicle"
              bundle="the name in <artifactId> in pom.xml"
              type="ship"/>
    <document class="com.mydomain.concretedocs2.Disease"
              bundle="the name in <artifactId> in pom.xml"
              type="disease"/>
    <search/>
    <document-processing>
        <chain id="default">
            <documentprocessor bundle="the name in <artifactId> in pom.xml"
                               id="concretedocs.ConcreteDocDocProc"/>
        </chain>
    </document-processing>
    <nodes>
        <node hostalias="node1"/>
    </nodes>
</container>

accesslog

Configures properties of the accesslog. The default type is json that will give output in (line-based) JSON format. See Access logging for configuration details. Setting the type to vespa gives a classic Apache CLF-like format.

Access logging can be disabled by setting the type to disabled.

Example:

<accesslog fileNamePattern="$VESPA_HOME/logs/vespa/access/JsonAccessLog.<container id>.%Y%m%d%H%M%S"
           symlinkName="JsonAccessLog.<container id>"
           rotationInterval="0 1 ..."
           type="vespa" />

include

Allows including XML snippets contained in external files. All files from all listed directories will be included. All files must have the same outer tag as they were referred from, i.e. search, document-processing or processing. The path must be relative to the application package root, and must never point outside the package.

Example:

<include dir="included_configs/search" />

nodes

The nodes element specifies the nodes that comprise this container cluster by adding node children.

environment-variables

Add children elements to nodes for environment variables - see example below. These are set before the services are started on the container node - available for the Container.

jvm

JVM settings for container nodes:

Example where 50% of the node total memory is used as the Max heap size of the JVM:

<nodes>
    <jvm gc-options="-XX:+UseG1GC -XX:MaxTenuringThreshold=10"
         options="-XX:+PrintCommandLineFlags"
         allocated-memory="50%" />
</nodes>

node

Example:

<nodes>
    <environment-variables>
        <KMP_SETTING>1</KMP_SETTING>
        <KMP_AFFINITY>granularity=fine,verbose,compact,1,0</KMP_AFFINITY>
    </environment-variables>
    <node hostalias="searchnode1" />
</nodes>

secret-store

The secret-store element holds configuration for custom implementations. Contains one or more group elements.

group

Example:

<secret-store type="my-ckms">
    <group name="[key group]" environment="[environment]"/>
</secret-store>

zookeeper

The zookeeper element declares that the container cluster should run ZooKeeper and configure the necessary components. This element has no attributes or children.