1 of 4

Server

Introduction

This is the documentation for common server functionality shared by all FortifiedID products.

Configuration is located in the top level block "server" in the main configuration:

Deployment

Controls how module deployment is done.

Actual deployment is done by the Node module (documented separately).

Name

Description

Default

{
    "server": {
        "deployment": {
            "groups": ["first", "custom", "default", "last"]
        }
    }
}

Groups

Groups are used for controlling the deployment order. Groups are processed in the defined order, all modules in a group are deployed before continuing with the next group.

Module group deployment can be verified in the log:

[NodeModule] INFO: Deploying module group: default
[NodeModule] INFO: Deploying module: NodeModuleTestDefault
... module start up logging ...
[NodeModule] INFO: Module group 'default' contained 1 module(s)

Empty groups are OK and will result in the following log:

[NodeModule] INFO: Deploying module group: empty
[NodeModule] INFO: Module group 'empty' contained 0 module(s)

If a module is assigned to an undefined group a warning will printed to the log and the module will not be deployed:

[NodeModule] WARN: Group(s) exist that are not configured for deployment: undefined

Cluster

Server cluster configuration. Clustering only applies to HTTP sessions, internal calls are never routed outside of the issuing node.

Clustering should be used in combination with sticky sessions to avoid issues cased by lagging cluster state synchronisation.

Clustering is not enabled by default.

Name

Description

Default

{
    "server": {
        "cluster": {
            "enabled": true,
            "config_path: "config/cluster.xml"
        }
    }
}

Cluster configuration

Clustering is provided by Hazelcast and is configured in a separate configuration file (by default: "config/cluster.xml").

In this file you can:

Change the port used for cluster communication
Add members

We recommend that cluster members are defined statically using their ip-address instead of using multicast.

<?xml version="1.0" encoding="UTF-8"?>
<hazelcast xmlns="http://www.hazelcast.com/schema/config"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://www.hazelcast.com/schema/config
           http://www.hazelcast.com/schema/config/hazelcast-config-4.2.xsd">
    <cluster-name>fortified</cluster-name>
    <network>
        <port auto-increment="false">5701</port>
        <join>
            <!-- static ip -->
            <multicast enabled="false"/>
            <tcp-ip enabled="true">
                <!-- cluster members -->
                <member>127.0.0.1</member>
            </tcp-ip>
            <!-- multicast -->
            <!--
            <multicast enabled="true">
                <multicast-group>224.2.2.3</multicast-group>
                <multicast-port>54327</multicast-port>
            </multicast>
            <tcp-ip enabled="false"/>
            -->
        </join>
    </network>
</hazelcast>

More information

https://vertx.io/docs/vertx-hazelcast/java/

HTTP listener

Cluster

Server cluster configuration. Clustering only applies to HTTP sessions, internal calls are never routed outside of the issuing node.

Clustering should be used in combination with sticky sessions to avoid issues cased by lagging cluster state synchronisation.

Clustering is not enabled by default.

Name

Description

Default

{
    "server": {
        "cluster": {
            "enabled": true,
            "config_path: "config/cluster.xml"
        }
    }
}

Cluster configuration

Clustering is provided by Hazelcast and is configured in a separate configuration file (by default: "config/cluster.xml").

In this file you can:

Change the port used for cluster communication
Add members

We recommend that cluster members are defined statically using their ip-address instead of using multicast.

<?xml version="1.0" encoding="UTF-8"?>
<hazelcast xmlns="http://www.hazelcast.com/schema/config"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://www.hazelcast.com/schema/config
           http://www.hazelcast.com/schema/config/hazelcast-config-4.2.xsd">
    <cluster-name>fortified</cluster-name>
    <network>
        <port auto-increment="false">5701</port>
        <join>
            <!-- static ip -->
            <multicast enabled="false"/>
            <tcp-ip enabled="true">
                <!-- cluster members -->
                <member>127.0.0.1</member>
            </tcp-ip>
            <!-- multicast -->
            <!--
            <multicast enabled="true">
                <multicast-group>224.2.2.3</multicast-group>
                <multicast-port>54327</multicast-port>
            </multicast>
            <tcp-ip enabled="false"/>
            -->
        </join>
    </network>
</hazelcast>

More information

https://vertx.io/docs/vertx-hazelcast/java/

Deployment

Controls how module deployment is done.

Actual deployment is done by the Node module (documented separately).

Name

Description

Default

{
    "server": {
        "deployment": {
            "groups": ["first", "custom", "default", "last"]
        }
    }
}

Groups

Groups are used for controlling the deployment order. Groups are processed in the defined order, all modules in a group are deployed before continuing with the next group.

Module group deployment can be verified in the log:

[NodeModule] INFO: Deploying module group: default
[NodeModule] INFO: Deploying module: NodeModuleTestDefault
... module start up logging ...
[NodeModule] INFO: Module group 'default' contained 1 module(s)

Empty groups are OK and will result in the following log:

[NodeModule] INFO: Deploying module group: empty
[NodeModule] INFO: Module group 'empty' contained 0 module(s)

If a module is assigned to an undefined group a warning will printed to the log and the module will not be deployed:

[NodeModule] WARN: Group(s) exist that are not configured for deployment: undefined