USER MANUALS

Launching Several Virtual DataPort Instances of the Same Installation

Note

This feature is deprecated and it may be removed in future major versions of the Denodo Platform.

If you are using this feature, configure Virtual DataPort to store the metadata in an external database instead (see section Storing the Metadata on an External Database).

This feature is not about starting two Virtual DataPort servers from two different installations of the Denodo Platform running on the same computer. Running two Virtual DataPort servers from different installations on the same computer is fully supported.

The section Features Deprecated in Denodo Platform 8.0 lists all the features that are deprecated.

It is possible to launch two or more instances of the same Virtual DataPort installation simultaneously, in the same host sharing the same metadata (data sources, views, etc.) and the same Web container. Each instance is executed independently, which means that each one is a different process of the operating system.

When executing two or more instances of the same Server, one of the instances is the Primary and the others are the Secondary instances. The Primary instance has to be launched before the Secondary instances.

Only the Primary instance can modify the metadata of the Server (create / edit / remove data sources, views, etc.).

When modifying the metadata, you have to restart all the Secondary instances so they “see” the changes. That is because the Secondary instances only read the metadata from the Primary when they are launched.

When defining a JMS listener, the Primary instance is the only one that opens the connection to the JMS server.

Virtual DataPort uses an embedded Derby database to store the metadata created by its users (data sources, views, etc.) The Secondary instances have access to the metadata of the elements by connecting to the embedded database of the Primary Server.

How to Configure the Secondary Instances

Let us say that we want to add two new Secondary instances called aux_1 and aux_2. To do this, follow these steps:

  1. Log in as an administrator, open the VQL Shell and execute the following commands:

SET 'vdp.instances' = 'aux_1,aux_2';

SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_1.port' = '19999';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_1.odbcPort' = '19996';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_1.registryURL' = 'localhost';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_1.registryPort' = '19997';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_1.factoryPort' = '19995';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_1.shutdownPort' = '19998';

SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_1.port' = '29999';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_2.odbcPort' = '29996';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_2.registryURL' = 'localhost';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_2.registryPort' = '29997';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_2.factoryPort' = '29995';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_2.shutdownPort' = '29998';

Note that for each element of the property vdp.instances, you have to define the following properties:

com.denodo.vdb.vdbinterface.server.VDBManagerImpl.<name of the instance>.port
com.denodo.vdb.vdbinterface.server.VDBManagerImpl.<name of the instance>.odbcPort
com.denodo.vdb.vdbinterface.server.VDBManagerImpl.<name of the instance>.registryURL
com.denodo.vdb.vdbinterface.server.VDBManagerImpl.<name of the instance>.registryPort
com.denodo.vdb.vdbinterface.server.VDBManagerImpl.<name of the instance>.factoryPort
com.denodo.vdb.vdbinterface.server.VDBManagerImpl.<name of the instance>.shutdownPort

  1. Optionally, you can configure the options of the Java Virtual Machine for each new instance. To do this, execute the following commands:

SET 'java.env.aux_1.DENODO_OPTS_START' = '-Xmx2g -XX:MaxPermSize=256m';
SET 'java.env.aux_1.DENODO_OPTS_STOP' = '-Xmx64m';

SET 'java.env.aux_2.DENODO_OPTS_START' = '-Xmx2g -XX:MaxPermSize=256m';
SET 'java.env.aux_2.DENODO_OPTS_STOP' = '-Xmx64m';

The property DENODO_OPTS_START has the JVM options that the instance will launched with.

The property DENODO_OPTS_STOP has the JVM options that the script that stops the Server will be launched with.

The Servers defined in the property vdp.instances that do not have the variables DENODO_OPTS_START and DENODO_OPTS_STOP defined, will be launched with the JVM options of the Primary server.

  1. In the installation, execute the script <DENODO_HOME>/bin/regenerateInstanceScripts.

    This script will create the directory <DENODO_HOME>/bin/instances, which will contain the scripts to launch the Secondary instances of the Primary Server.

    For each instance, there will be:

    1. A script to launch the instance: vqlserver_<name of the instance>_startup

    2. A script to stop the instance: vqlserver_<name of the instance>_shutdown

      To stop the instance with the “Safe shutdown mode”, execute vqlserver_<name of the instance>_shutdown safe

      When doing this, the instance will stop accepting new connections and it will not shut down until all the queries have finished.

    3. If running the Server in Windows, a script to create a new Windows service, remove it, launch and stop the service: vdpservice_<name of the instance>.bat

  2. Launch the Primary instance before the Secondary instances. You can do it from the Denodo Control Center or executing the script <DENODO_HOME>/bin/vqlserver_startup.bat.

  3. Execute the following scripts to launch the Secondary instances:

    • <DENODO_HOME>/bin/instances/vqlserver_aux_1_startup

    • <DENODO_HOME>/bin/instances/vqlserver_aux_2_startup

  4. In the secondary instances, disable the Cache Maintenance Task.

    To do this, open the dialog “Cache” of the “Administration > Server configuration” menu and select Maintenance Off.

  5. To stop the instances, you have to stop the Secondary instances first and after this, the Primary.

Now, users can connect to any of the three instances (the Primary or the Secondaries) to query views. However, they have to connect to the Primary instance to modify the metadata of the Server. That is, to create/edit/delete data sources, views, publish Web services, etc.

Deploying Web Services on This Configuration

If Virtual DataPort runs on a Primary/Secondary configuration, the wizard to deploy web services will also show the Virtual DataPort server URI box. In this box you have to enter the URI of the Virtual DataPort server that you want this service to connect to. This is necessary because in a Primary/Secondary configuration there is only one embedded Web container running, but the services running in it can connect to any of the Virtual DataPort instances. In this URI, the host name is the same for all the instances because they all run in the same host. But the port number is different for each instance.

Add feedback