This task will show you how to install manually a vault server on UNIX.
On Windows, we recommend that you install a vault server using the interactive tools provided.
Beware: Each Vault Server is supposed to have its own data structure. Do not share Vault Server data structure between several Vault Server!
You will find the reference files for the data structure creation (tables, index, etc.) under the following directory:
YourUnloaddir/$OSDS/reffiles/DBMS/ddl
The $OSDS value could be aix_a, hpux_b or solaris_a depending on your operating system.
The suffix of these reference files is .clp for DB2 and .sql for Oracle.
They are named:
VPM_VAULTFILE.clp and VPM_VAULTFILE.sql when creating tables
grant_VPM_VAULTFILE.clp and grant_VPM_VAULTFILE.sql when creating grants on tables
You can also use the drop_VPM_VAULTFILE.xxx and the revoke_VPM_VAULTFILE.xxx files to remove respectively tables and grants on tables.
When creating your data structure, you have to customize the above-mentioned files.
To do so:
1. Duplicate the following files and rename them as indicated below:
Original file name: Duplicated file name:
VPM_VAULTFILE.xxx
VPM_VAULTFILE_MyVault.xxx
grant_VPM_VAULTFILE.xxx
grant_VPM_VAULTFILE_MyVault.xxx
drop_VPM_VAULTFILE.xxx
drop_VPM_VAULTFILE_MyVault.xxx
revoke_VPM_VAULTFILE.xxx
revoke_VPM_VAULTFILE_MyVault.xxx
2. Change the name of the structure owner (the default owner is VPMADM) and the tablespaces name if necessary. In the case of the grant file, we advise you to change the "to public" right into "to vault_structure_owner".
3. Execute the VPM_VAULTFILE_MyVault.xxx file and the related grant file (grant_VPM_VAULTFILE_My_Vault.xxx) on your database:
a. Logon to the database as Database Administrator
For DB2:
b. Under the DB2 prompt, run the command:
db2 -tvf file_fullpathname.clpFor Oracle:
b. Under sqlplus, run the command:
start file_fullpathname.sql
1. Execute the following command:
IT_CONFIG_PATH= install_dir/startup/orbix
export IT_CONFIG_PATH
Run it using catstart, or export the environment before like
this:
catstart -env -direnv -run
"/bin/ksh"
Putit -h
machine_name -shared
VaultServerName
"install_dir/code/command/catstart -env
\"env_name\" -direnv
\"env_dir" -run
install_dir/code/command/runENOVVaultStarter -object
\"
MyVaultOwner_UID MyVaultOwner_GID env_name env_dir\ ""
chmodit VaultServerName i+all
chmodit VaultServerName l+all
The values for the parameters are:
VaultServerName: name of the CORBA service for the VaultServer.
Beware:'_' are not allowed in the Vault server name and the Vault server alias name!
MyVaultOwner_UID: UNIX user id of the vault administrator user.
MyVaultOwner_GID: UNIX group id of the vault administrator user.
IT_CONFIG_PATH: path of the iona.cfg file under the installation.
On a standard installation, this file is under startup/orbix directory.
Example:
With the values below:
Install_dir:
/usr/DassaultSystemes/B18/solaris_a
Machine: reverdsy
VaultServerName: ENOVIAVaultServer
Env_name:
ENOVIA_V5_VPM.V5R18.B18
Env_dir: /CATEnv
MyVaultOwner_UID: 1400
MyVaultOwner_GID: 360
We get:
IT_CONFIG_PATH=
/usr/DassaultSystemes/B18/solaris_a/startup/orbix
export IT_CONFIG_PATH
Putit -h
reverdsy -shared
ENOVIAVaultServer "/usr/DassaultSystemes/B18/solaris_a/startup/orbix/code/command/catstart
-env
\"ENOVIA_V5_VPM.V5R18.B18\" -direnv
\"/CATEnv" -run
/usr/DassaultSystemes/B18/solaris_a/startup/orbix/code/command/runENOVVaultStarter
-object
\"1400
360 ENOVIA_V5_VPM.V5R18.B18 /CATEnv\""
chmodit ENOVIAVaultServer i+all
chmodit ENOVIAVaultServer l+all
If all is OK, you should have a ENOVIAVaultServer.imp file under the following directory:
YourUnloaddir/$OSDS/startup/orbix/config/Repositories/ImpRep
Then you have created the Orbix service name ENOVIAVaultServer.
The
above command will generate a file named ENOVaultServer.imp in the
directory:
/home/DS/B18/solaris_a/startup/orbix/config/Repositories/ImpRep.
The
file ENOVaultServer.imp looks like this:
Name
: ENOVaultServer
Comms : cdr/tcp
Activation : shared
Owner :
root
Launch :
;all;
Invoke :
;all;
ImpRep Version : 2
no. of servers : 1
server's port : 0
Marker Launch Command * /home/DS/B18/solaris_a/code/command/runENOVVaultStarter
1415 363
The new Vault Setting software is based on an extended JAVA properties mechanism. So the Vault Setting file looks like a java property file. When the Vault tries to get a property, the search order is:
1. in system properties (java only: "-D" option in launch command line)
2. in environment (shell variables)
3. in vault properties file.
There are two kinds of Vault settings: server and client.
Each Vault Server is supposed to have its own Vault Server properties file. Do not mix properties of two Vault Server in the same properties file. It is not supported!
The default location of the Vault server settings file is:
install_dir/docs/java
The default filename is no longer VaultServer.properties, but:
VaultServerName.properties
VaultServer setting purpose
VaultServer settings are used to manage:
Here are keys used by a VaultServer:
Mandatory Keys
VaultServer_Name
: vault server Orbix service name
VaultServer_HostName
: vault server host name
VaultServer_DaemonPort :
Orbix daemon listen port
VaultServer_TimeOut
: vault server timeout (unit: milli second)
VaultServer_ThreadNumber : number of thread
waiting for client request
VaultServer_DBMINPoolSize : minimum
number of connections for the vault server database connection pool
VaultServer_DBMAXPoolSize : maximum number of
connections for the vault server database connection pool
VaultServer_TimeZoneRawOffset : time zone offset (unit: milli second),
used for document creation
and modification date
VaultServer_DBName
: name of the database where vault tables are
VaultServer_DBVendor
: database vendor pertaining to the database name above
VaultServer_DBUser
: database connection user
VaultServer_DBSchema
: database structures owner
VaultServer_DBPassword :
database connection user password
For detailed information about how to generate the password, refer to the description of the GenVaultPassword command in Database password encryption for the Vault Server properties file.
VaultServer_NumOfRepo :
number of Vault Server repositories
VaultServer_Repo_x_Name : name of the Vault
Server repository
VaultServer_Repo_x_Path : path of the
Vault Server repository
For more information, refer to Multiple File System Support.
Beware: the following keys are no longer valid since release V5R8:
VaultServer_Default_Secured_StorageLocation
: default vault secured path for files
VaultServer_Default_Tmp_StorageLocation :
default vault temporary path for files
Those keys are
still allowed but they can't be mixed with the keys replacing them (VaultServer_NumOfRepo,
…),
it is not supported!
Optional Keys
Standard optional Keys:
VaultServer_TmpFilesAccessRights
: file access rights under temporary path (default: 600)
VaultServer_SecuredFilesAccessRights : file access
rights under secured path (default: 400)
VaultServer_LogRemovedFiles
: trigger logging of delete operations (default: false)
VaultServer_RemoveFiles
: trigger file delete on disk (default: true)
VaultServer_IsDBPasswordEncrypted :
trigger password encryption use (default: true)
VaultServer_DBURL
: JDBC connection string
VaultServer_DBDriver
: JDBC driver class to load
VaultServer_DBTransIsoLevel
: database transaction isolation level
VaultServer_FDSMIN
: free disk space threshold
VaultServer_Repo_x_ReadOnly
: trigger read only mode on a Repo (default: false)
VaultServer_Repo_x_Priority
: modifies use frequency (unit: double, default: 1.0)
VaultServer_Repo_x_NumOfSecDir
: number of secured directories for the repository number x
(default: 1)
VaultServer_Repo_x_TmpDirName
: name of the tmp directory for the repository number x (default:
tmp)
VaultServer_Repo_x_SecDirName_y
: name of the secured directory for the repository number x
(default: securedy)
VaultServer_ENOVIStorageLocation_Implementation: class to load for storage
location user exit
VaultServer_ENOVIDocIndexation_Implementation : class to load for document
indexation user exit
VaultServer_MilliSecondTimestamp
: trigger timestamp millisecond precision (default: true on DB2 and false
on ORACLE)
VaultServer_ReadOnly :
trigger read only mode on the whole vault
VaultServer_Trace : trigger trace (default: OFF)
VaultServer_LicenseName : forces the use of a particular
license (instead of VAR); this license must be an authorized
license for the VSA product
Optional Keys for DB2 DATALINK
VaultServer_DB2DATALINK
: trigger datalink mode (default: false)
VaultServer_DLFMHostServerName
: datalink file manager host server name (only for datalink mode)
Optional Keys for a Cache VaultServer
VaultServer_Cache
: trigger cache mode (default: false)
VaultServer_Cache_MaxSize
: Maximum size of Vault Cache (unit: kb)
VaultServer_Cache_CleanThreshold :
threshold for cleaning file (percent of cache max size)
VaultServer_Cache_CleanRate
: targeted size after cleaning (percent of cache max size)
VaultServer_Cache_CleanEnabled
: trigger cleaning mode on (default: true)
VaultServer_Cache_TimeoutForClean : time between
two cleaning (unit: milli second)
Standard VaultServer properties file example
## Vault Server
Properties File
## Orbix parameters
VaultServer_Name
= ENOVIAVaultServerOrbSrv
VaultServer_HostName
= regis
VaultServer_DaemonPort =
1572
VaultServer_TimeOut
= 36000000
## Request
execution parameters
VaultServer_ThreadNumber = 2
VaultServer_TimeZoneRawOffset = 3600000
## Database
connection pool parameters
VaultServer_DBMINPoolSize = 4
VaultServer_DBMAXPoolSize = 6
## Database
connection parameters
VaultServer_DBName
= AIXINT8
VaultServer_DBVendor
= oracle
VaultServer_DBUser
= tacr
VaultServer_DBPassword =
******
## VaultServer
file repositories parameters
VaultServer_NumOfRepo
= 2
VaultServer_Repo_0_Name = Repo0
VaultServer_Repo_0_Path =
/VAULTCXR8/Repo0
VaultServer_Repo_0_NumOfSecDir = 2
VaultServer_Repo_0_TmpDirName = TmpDirectory
VaultServer_Repo_0_SecDirName_0 = SecuredDirectory0
VaultServer_Repo_0_SecDirName_1 = SecuredDirectory1
VaultServer_Repo_1_Name = Repo1
VaultServer_Repo_1_Path =
/VAULTCXR8/Repo1
## Trace
parameter
VaultServer_Trace
= OFF
Explanation of Example
This properties file is corresponding to a standard VaultServer (no DATALINK or VaultCache) running on a workstation named "regis". The Orbix service name, which is the name declared is registered on the Orbix daemon, is ENOVIAVaultServerOrbSrv. The Orbix daemon is listening on port 1572 on this workstation. The VaultServer timeout is exactly ten hours. Two request execution threads and four database connections are created at start time. The server time zone is GMT+1. The database used is an Oracle database named AIXINT8 and the connection user is tacr. Two Vault repositories are declared.
Several Vault Clients can use the same Vault Client properties file.
VaultClient setting purpose
VaultClient settings are used for:
VaultAliasName concept:
The VaultAliasName is the way for VaultClient applications to identify a VaultServer. A VaultClient application needs three data to connect a VaultServer. It needs VaultServer Orbix service name, Orbix listen port on the remote workstation where VaultServer is running and the remote workstation name. VaultClient properties file is used to link a given VaultAliasName to the three data identifying a given VaultServer.
Here are the keys used by a VaultClient:
Mandatory Keys
VaultClient_DefaultAliasName : default vault
alias name
VaultClient_ReadProtocol
: number of allowed read protocol
VaultClient_ReadProtocol_0 : first read protocol
VaultClient_ReadProtocol_1 : second read protocol
VaultClient_WriteProtocol :
number of allowed write protocol
VaultClient_WriteProtocol_0 : first write protocol
VaultClient_BlockSize
: size in bytes of block for read and write operation
Optional Keys
VaultClient_Active_ReadProtocol : file transfer protocol to use for
read operation
VaultClient_Active_WriteProtocol : file transfer protocol to use for
write operation
VaultClient_ReadOnly : trigger read only mode (default: false)
VaultClient_Trace
: traces activation (java only, default: OFF)
How to catalog a new VaultServer
In order to do that, you have to declare a new VaultAliasName pertaining to the VaultServer you want to catalog. As read and write operations are separate, you have to add six data by VaultAliasName which are:
VaultClient_MyVaultAliasName_ReadVaultServerName
:
Orbix service name of the target vault server for read operation
VaultClient_MyVaultAliasName_ReadVaultServerHostName :
Host name of the target vault server for read operation
VaultClient_MyVaultAliasName_ReadVaultServerDaemonPort :
Orbix listen port of the target vault server for read operation
VaultClient_MyVaultAliasName_WriteVaultServerName
:
Orbix service name of the target vault server for write operation
VaultClient_MyVaultAliasName_WriteVaultServerHostName :
Host name of the target vault server for write operation
VaultClient_MyVaultAliasName_WriteVaultServerDaemonPort :
Orbix listen port of the target vault server for write operation
These keys are mandatory for the default alias name.
You can catalog as many VaultServers as you want in a VaultClient properties file. But do not declare a VaultAliasName twice. Only the first entry will be taken into account.
VaultClient properties file example:
## Vault Client Properties File
VaultClient_DefaultAliasName
= Vault1
VaultClient_ReadProtocol
= 2
VaultClient_ReadProtocol_0
= CORBA
VaultClient_ReadProtocol_1
= NFS
VaultClient_WriteProtocol
= 2
VaultClient_WriteProtocol_0
= CORBA
VaultClient_WriteProtocol_0
= NFS
VaultClient_BlockSize
= 262144
VaultClient_Trace
= OFF
## Vault1 alias entry
VaultClient_Vault1_ReadVaultServerName
= Vault1OrbSrv
VaultClient_Vault1_ReadVaultServerHostName =
laureen
VaultClient_Vault1_ReadVaultServerDaemonPort = 1570
VaultClient_Vault1_WriteVaultServerName
= Vault1OrbSrv
VaultClient_Vault1_WriteVaultServerHostName = laureen
VaultClient_Vault1_WriteVaultServerDaemonPort = 1570
## Vault2 alias entry
VaultClient_Vault2_ReadVaultServerName
= Vault2OrbSrv
VaultClient_Vault2_ReadVaultServerHostName =
floydsy
VaultClient_Vault2_ReadVaultServerDaemonPort = 1572
VaultClient_Vault2_WriteVaultServerName
= Vault2OrbSrv
VaultClient_Vault2_WriteVaultServerHostName = floydsy
VaultClient_Vault2_WriteVaultServerDaemonPort = 1572
## Vault3 alias entry
VaultClient_Vault3_ReadVaultServerName
= Vault3OrbSrv
VaultClient_Vault3_ReadVaultServerHostName =
bayeux
VaultClient_Vault3_ReadVaultServerDaemonPort = 1576
VaultClient_Vault3_WriteVaultServerName
= Vault3OrbSrv
VaultClient_Vault3_WriteVaultServerHostName = bayeux
VaultClient_Vault3_WriteVaultServerDaemonPort = 1576
Explanation of Example
This VaultClient properties file declares three VaultAliasName that are Vault1, Vault2 and Vault3. The VaultServer Vault1OrbSrv Orbix service name is associated to the Vault1 alias name. This VaultServer is running on a workstation named laureen and the Orbix daemon listen port is 1570. The VaultServer Vault2OrbSrv Orbix service name is associated to the Vault2 alias name. The VaultServer Vault3OrbSrv Orbix service name is associated to the Vault3 alias name.
Properties file access path:
The vault application default access path for properties file is:
unload_dir/$OSDS/docs/java
You can change this behavior by exporting the keys below in your environment:
VaultServer_PropertiesFilePath : Path
of the vault server properties file
VaultServer_PropertiesFileName : Name
of the vault server properties file
VaultClient_PropertiesFilePath : Path
of the vault client properties file
VaultClient_PropertiesFileName : Name of the vault
client properties file
For instance:
VaultServer_PropertiesFilePath=/u/lego/VAULTServer/PropertiesV5R18
export VaultServer_PropertiesFilePath
VaultServer_PropertiesFileName=CustomVaultServer.properties
export VaultServer_PropertiesFileName
VaultClient_PropertiesFilePath=/u/lego/VAULTClient/PropertiesV5R18
export VaultClient_PropertiesFilePath
VaultClient_PropertiesFileName=CustomVaultClient.properties
export VaultClient_PropertiesFileName
Beware: '_' are not allowed in Vault server name and Vault server alias name!
In order to allow declaration of tmp and secured directories on several file systems, the concept of Vault Server Repository has been introduced. A Vault Server Repository is defined by a name, a tmp directory and a set of secured directories. These directories have to be on the same file system for a given Vault Server Repository. It is necessary to improve performances and reliability. The following Vault Server properties have been added to support this new feature.
Vault Server Repository Definition Keys
Mandatory Keys
Number of Vault Server
Repositories: VaultServer_NumOfRepo.
For instance, the line:
VaultServer_NumOfRepo = 2
means that two Vault Server Repositories are defined below.
Repository name:
VaultServer_Repo_x_Name
(x stands for the repository index rank. It begins at 0)
For instance, the line:
VaultServer_Repo_0_Name = Repo0
means that the name of the Vault Server Repository number 0 is Repo0.
Repository path:
VaultServer_Repo_x_Path
(x stands for the repository index rank. It begins at 0)
This property defines the root path under which tmp and secured directories are supposed to be created.
For instance:
VaultServer_Repo_0_Path = /VAULTCXR8/Repo0
means that tmp and secured directories are created under the directory /VAULTCXR8/Repo0
Optional Keys
Minimum free disk space
threshold (unit: kb): VaultServer_FDSMIN.
For instance, the line:
VaultServer_FDSMIN = 1000
means that the Vault Server will not use a file system any more if there is less than 1000 free kb on it. Default value for this property is: 0.
Tmp directory name: VaultServer_Repo_x_TmpDirName
(x stands for the repository index rank. It begins at 0)
For instance, the line:
VaultServer_Repo_0_TmpDirName = tmpDir0
means that the tmp directory for Vault Server repository named Repo0 is /VAULTCXR8/Repo0/tmpDir0. The default value for this property is: tmp.
Number of secured directories
definition key: VaultServer_Repo_x_NumOfSecDir
(x stands for the repository index rank. It begins at 0)
For instance the line:
VaultServer_Repo_0_NumOfSecDir = 2
means that two secured directories are defined below. The default value for this property is: 1.
Secured directory name:
VaultServer_Repo_x_SecDirName_y
(x stands for the repository index rank. It begins at 0; y stands for the secured directory index rank. It begins at 0)
For instance, the line:
VaultServer_Repo_0_SecDirName_0 = secDir0
means the the first secured directory for Vault Server Repository named Repo0 is /VAULTCXR8/Repo0/secDir0. The default value for this property is: securedy (where y stands for the secured directory index rank. It begins at 0)
Read only feature:
VaultServer_Repo_x_ReadOnly
(x stands for the repository index rank. It begins at 0)
For instance, the line:
VaultServer_Repo_0_ReadOnly = true
means that the Vault Server repository named Repo0 is read only. The default value for this property is: false.
Priority feature:
VaultServer_Repo_x_Priority
(x stands for the repository index rank. It begins at 0)
For instance, the line:
VaultServer_Repo_0_Priority = 2.0
means that the Vault Server repository named Repo0 is two-time more used than it would be by default when creating new documents. The default value for this property is: 1.0.
Example:
Vault Server properties file example
# Vault Server Repositories
# Number of Vault Server
Repositories
VaultServer_NumOfRepo = 3
# First Vault Server Repo
VaultServer_Repo_0_Name = Repo0
VaultServer_Repo_0_Path = /VAULTCXR8/DirOfRepo0
VaultServer_Repo_0_TmpDirName = TmpDirOfRepo0
VaultServer_Repo_0_NumOfSecDir = 2
VaultServer_Repo_0_SecDirName_0 = SecDir0OfRepo0
VaultServer_Repo_0_SecDirName_1 = SecDir1OfRepo0
# Second Vault Server Repo
VaultServer_Repo_1_Name = Repo1
VaultServer_Repo_1_Path = /VAULTCXR8/DirOfRepo1
VaultServer_Repo_1_NumOfSecDir = 3
# Third Vault Server Repo
VaultServer_Repo_2_Name = Repo2
VaultServer_Repo_2_Path = /VAULTCXR8/DirOfRepo2
The lines above mean that the following directories are supposed to be created for Repo0, Repo1 and Repo2:
Repo0:
/VAULTCXR8/DirOfRepo0/TmpDirOfRepo0
/VAULTCXR8/DirOfRepo0/SecDir0OfRepo0
/VAULTCXR8/DirOfRepo0/SecDir1OfRepo0
Repo1
/VAULTCXR8/DirOfRepo1/tmp
/VAULTCXR8/DirOfRepo1/secured0
/VAULTCXR8/DirOfRepo1/secured1
/VAULTCXR8/DirOfRepo1/secured2
Repo2
/VAULTCXR8/DirOfRepo2/tmp
/VAULTCXR8/DirOfRepo2/secured0
File dispatching rules
A user exit mechanism (ENOVIStorageLocation interface) is used to know where to write new or modified files into Vault repository directories. If you want to code your own user exit, keep in mind that the code has to be thread safe.
The default user exit implementation we supply dispatch files depending on free disk space on file system. The more free disk space you have on a file system, the more you will have new or modified files written on it.
The file dispatching rule is not verified with one single file but it is a statistic rule. For example, there are two vault repositories (REPO1 and REPO2) such that REPO2 free disk is space equal to 2 times REPO1 then the file distribution will be such that 1/3rd of files will go in REPO1 and 2/3rd will go in REPO2.
So If you have 3000 files you will have 1000 files in REPO1 and 2000 in REPO2. Of course this rule can not verified if you have only 1 file.
On a given Vault repository, there is no preference between secured directories. The free disk space is not computed per secured directory but it is calculated per Vault repository. So if there are 1000 files in a Vault Repo with 10 secured directories (all created at Vault repository creation time) then you will have 100 files stored per secured directory.
Creation of secured and tmp directory for VaultServer.
For each defined Vault Server repository create tmp and secured directories:
mkdir -p
directory_to_createchmod +rw just_created_directoryCLASSPATH issue on vault client and vault server side: the Vault client and server software component are based on JNI operations for file access rights management. So, make sure the JNIVAULT.jar file is in your CLASSPATH.
DB2 mandatory environment variables for JDBC use (vault server side only):
DB2INSTANCE has to be set. For instance:
DB2INSTANCE=admclien
export DB2INSTANCECLASSPATH issue on vault server side for JDBC use: add d
b2client_home_directory/sqllib/java/db2java.zipto your CLASSPATH (see db2profile shell in the DB2 client installation to set the value of this variable properly).LIBPATH (or LD_LIBRARY_PATH ...) issue on vault server side for JDBC use:
db2client_home_directory/sqllib/libhas to be in LIBPATH (see db2profile shell in the DB2 client installation to set the value of this variable properly).
ORACLE mandatory environment variables for JDBC use (vault server side only)
NLS_LANG has to be set (US7ASCII, WE8DEC, WE8ISO8859P1, UTF8, ...). This variable is set by default by the Oracle installation. So, you can just keep the default value. For instance:
NLS_LANG=FRENCH_FRANCE.WE8ISO8859P1
export NLS_LANGORACLE_HOME has to be set. For instance:
ORACLE_HOME=/u/env/oracle/SunOS
export ORACLE_HOMETNS_ADMIN has to be set. For instance:
TNS_ADMIN=/u/env/oracle/SunOS/network/adminµ
export TNS_ADMINCLASSPATH issue on vault server side for JDBC use:
UNIX:
Add
$ORACLE_HOME/jdbc/lib/classes111.zipand$ORACLE_HOME/jdbc/lib/nls_charset11.zipto your CLASSPATHWindows XP:
Add
[ORACLE_HOME]\jdbc\lib\classes111.zipand[ORACLE_HOME]\jdbc\lib\nls_charset11.zipto your CLASSPATH.Set THREAD_FLAG variable to native value:
THREAD_FLAG=nativeLIBPATH (or LD_LIBRARY_PATH ...) issue on vault server side for JDBC use:
Unix:
$ORACLE_HOME/lib:$ORACLE_HOME/jdbc/libhas to be in LIBPATH.Windows XP:
Add [ORACLE_HOME]\lib:[ORACLE_HOME]\jdbc\lib to your PATH.
Dealing with OS limit parameters
The communications between the Vault Client and Vault Server are using TCP/IP sockets. Each socket represents a file descriptor on the Vault Server process. If the file descriptor limit per process is set too low, attempts to open socket connections may be unsuccessful. To resolve this condition, increase the file descriptor limit for the user from which the Orbixd process is started (normally root). Edit the .profile for the user, and add the following:
ulimit -n 1024
Depending on the number of connections needed, this number may need to be increased more. For this change to take effect, you do not have to reboot. Just logoff and then logon again.
Solaris
To change the hard upper limit of the number of file descriptors in the kernel (which defaults to 1024 per CPU), you can, edit the /etc/system config file to include a couple of entries:
set rlim_fd_max=4096
set rlim_FD_cur=1024
After you change this file, you must reboot for the changes to take effect.
HP-UX
HP-UX kernel parameter configuration for Java™ support
Threads
The default values for HP-UX 11.0 are set too low for VaultServer application. Two kernel parameters need to be set so that the limit of the maximum number of threads per process is not encountered. Usually you will see this problem as a Java Out of Memory error. You will want to set the value of the max_thread_proc higher than the expected maximum number of simultaneously active threads for your application
max_thread_proc
The maximum number of threads allowed in each process. The minimum value (and default) is 64, often too low for VaultServer application. The maximum value is the value of nkthread.
nkthread
The total number of kernel threads available in the system. This parameter is similar to the nproc tunable except that it defines the limit for the total number of kernel threads able to run simultaneously in the system. The value must be greater than nproc. The default is approximately twice that of nproc. The maximum is 30000.The suggested value of nkthread is 2*max_thread_proc. If you have many Java processes running and each running process uses many threads, you will want to increase this value.
open files
Problems occur when the value of kernel parameters are set too low for the number of files allowed to be simultaneously open in a process. Be certain that your kernel is configured so that you do not reach the limit for the number of open files for your process. Java opens many files in order to read in the classes required to run your application. A file descriptor is also used for each socket that is opened.
nfiles
Maximum number of open files.
This value is usually determined by the formula:
((NPROC*2)+1000)
NPROC is usually: ((MAXUSERS*5)+64)
For a MAXUSERS of 400, this works out to 5128. You can usually set it higher.
maxfiles
Soft file limit per process
maxfiles_lim
Hard file limit per process
2048 is the maximum value you can set through SAM for maxfiles and maxfiles_lim. Note that you can set the parameters higher by configuring the kernel using the configuration file and then rebuilding the kernel (or by modifying stand/system and doing a mk kernel). Since setting these parameters too low results typically in application failure, you may want to calculate the number you need and then double it. You might also considerinodealong with these parameters, that is as a member of the "set". If there's no space in the appropriateinodetable then you cannot open a new file.
timeouts
If the number of pending timeouts on the system exceeds the maximum number of
allowable pending timeouts on the system then the system will crash. This
undesireable behavior can be avoided by increasing the following kernel
parameter:
ncallout
Maximum number of pending timeouts
If you are opening many sockets, many of which are waiting on I/O, you will likely run into this limit.
Set ncallout to a value greater than the sum of:
nkthread + the number of I/O devices connected to the machine
A callout structure is used by each thread that sleeps waiting for a
time-based event. Traditionally the callout structure used by a thread is taken
from a pool the size of which is controlled by ncallout. Each thread has a set
of timers associated with it, e.g. for nanosleep or sleeping in select(). There
are a set of BringYourOwnCallout functions that don't allocate from the pool.
The maximum number of callout structures needs to be approximately the maximum
number of threads.
Interactively setting user limits
If you suspect that you are running out of file descriptors, you can check your limits by switching to the Bourne Shell and resetting the limits. Simply type in the following:
>sh
>ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 65536
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4290772993
nofiles(descriptors) 200
>
Use the first character to reset any of the values. For example, to increase the number of file descriptors, simply type:
>ulimit -n 5000
>ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 65536
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4290772993
nofiles(descriptors) 5000
>
Try re-running your application. (Do not exit the shell in which you've just reset your limits.)
Important warning for the installation of a vault running on an AIX server and a local DB2 database
You have to implement a client/server database connection for the vault, because of a limitation in the number of JDBC connections that the VaultServer can open.
Otherwise an SQL1224N error is triggered when the vault is started.
So, if you had initially an AIX vault with a local DB2 server (resulting from a standard installation, a migration of a former configuration, ...) you need to modify the database connectivity for the vault.
You will have to run the appropriate db2 commands to catalog your local database under an alias which will be accessible through a client/server connection. (typically, "db2 catalog tcpip node" + "db2 catalog database at node" statements)
Then you will have to update your Vault server java properties, referencing the new db2 alias as the VaultServer_DBName parameter.
Here is how to by-pass this limitation:
Modifying the Vault Server to Use Java Runtime Environment (JRE) |
|
On UNIXEdit the runENOVVaultServer shell: $ and make the following changes. Add the following before the echo "Starting ENOVIA V5 VAULT SERVER..... statement
Stop the Vault Server, if running, to ensure it will use the JRE 1.5 the next time it starts. |