Service-specific settings reside in the conf
folder of PTV xServer installations. They are split into functional and non-functional parameter files.
Non-functional parameters are defined in the file <service>.properties
(e.g. xroute.properties
).
Two settings in this file have to be configured in any productive PTV xServer installation: First, PTV xServer come pre-packaged with a map sample intended for testing and demonstration purposes; for live operations, you need to provide the path to the top level folder of the intended map data in setting maps.path
.
Second, if your hardware resources permit, you can and should start more than one worker process by increasing poolSize
in order to increase responsiveness, throughput, and overall service availability.
All other parameters can usually remain on their factory settings.
The following table explains all settings in detail:
key |
default | description | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
maps.path
|
|
path to the map folder; this should point to the map data folder you intend to use |
||||||||||||||||||||
poolSize |
1 or 2 (varies per server) |
The number of module instances to be started as background processes. |
||||||||||||||||||||
requestQueueTimeout |
60000 |
The maximum time in ms a request may remain in the request queue before there is a module available to process the request. |
||||||||||||||||||||
moduleTimeout |
(varies per server) |
Maximum time allowed for a single engine request in ms. |
||||||||||||||||||||
jobQueueTimeout |
-1 |
The maximum time in ms a single asynchronous job may remain in the request queue before there is a module available to process the job. (-1 disables the timeout) |
||||||||||||||||||||
jobModuleTimeout |
-1 |
Maximum time allowed for a single asynchronous job in ms. -1 means no timeout. |
||||||||||||||||||||
|
{jre}/bin/java -Xms32M -Xmx128M -Xss8M -XX:ErrorFile={log}/hs_err_pid%p.log -XX:-CreateMinidumpOnCrash -cp {cp} -Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector -Dxmoduleinstance={suf}{###} -Dxserver.logdirectory={log} -Dxserver={nam} -Dxserver.moduleid={ins} -Djava.rmi.server.hostname=localhost -Dcatalina.base={cbd} -Djava.library.path={lib} {cls} {suf} {prt} |
Don't touch this key if you are not sure what you are doing! The command to be executed for starting worker processes. This command string is passed to the exec-routine, replacing the following "parameters" with their according values:
|
Functional parameters are defined in profiles. These parameters are likely to remain stable between requests and usually impact behavioural details in the service modules. Therefore, they are usually not part of the regular API. In rare cases there are also options in the API with the same function; these options, if provided, override profile settings.
Depending on the service, profiles can also be properties files, or already in the revamped unified XML format. The old properties files also reside in the conf
folder, while new xml files are located in conf/profiles
.
Unified XML profiles are explained in detail in a separate chapter. They will fully replace properties profiles in the upcoming releases.
Properties profiles have the form <service>-<profile>.properties
where profile
stands for the profile name. default
stands for the default profile. If a client specifies a certain profile in the request caller context, parameters are looked up in the according profile parameter set. If that file does not exist, or if the according value is not specified in the named profile set, the value is taken from the default profile.
Copyright © 2024 PTV Logistics GmbH All rights reserved. | Imprint