Launching Several Virtual DataPort Instances of the Same Installation¶
This feature is deprecated and it may be removed in future major versions of the Denodo Platform.
We advise against beginning to use this feature if you are not doing so already.
If you are already using it, in the next major version of Denodo (Denodo 8.0), you can configure Virtual DataPort to store the metadata in an external database. This allows you to create a cluster of Virtual DataPort servers, in which all the servers share the same external database.
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_2. To do this, follow these steps:
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.registryURL' = 'localhost';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_1.registryPort' = '19999';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_1.shutdownPort' = '19998';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_1.factoryPort' = '19997';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_1.odbcPort' = '19996';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_2.registryURL' = 'localhost';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_2.registryPort' = '29999';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_2.shutdownPort' = '29998';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_2.factoryPort' = '29997';
SET 'com.denodo.vdb.vdbinterface.server.VDBManagerImpl.aux_2.odbcPort' = '29996';
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>.registryURL
com.denodo.vdb.vdbinterface.server.VDBManagerImpl.<name of the instance>.registryPort
com.denodo.vdb.vdbinterface.server.VDBManagerImpl.<name of the instance>.shutdownPort
com.denodo.vdb.vdbinterface.server.VDBManagerImpl.<name of the instance>.factoryPort
com.denodo.vdb.vdbinterface.server.VDBManagerImpl.<name of the instance>.odbcPort
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';
DENODO_OPTS_STARThas the JVM options that the instance will launched with.
DENODO_OPTS_STOPhas the JVM options that the script that stops the Server will be launched with.
The Servers defined in the property
vdp.instancesthat do not have the variables
DENODO_OPTS_STOPdefined, will be launched with the JVM options of the Primary server.
In the installation, execute the script
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:
A script to launch the instance:
vqlserver_<name of the instance>_startup
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.
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
Launch the Primary instance before the Secondary instances. You can do it from the Denodo Control Center or executing the script
Launch the Secondary instances by executing the following scripts:
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.
To stop the instances, you have to stop the Secondary instances first and after this, the Primary.
Now you can connect to any of the three instances (the Primary or the Secondaries) to query views. However, you 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.