Configuration of Rendering Service
This document describes the Rendering Service (also sometimes referred to as the Rendering Worker Service) - an application providing worker threads for handling Camunda tasks that ships with priint:suite 4 - Publishing Server.
You need Java 17 to run the rendering-service.
1. Configuring Application Properties
Your pubserver uses either Adobe InDesign Server® (short: ids) or priint:pdf renderer (short: pdf). Depending on the renderer type the Rendering Service must use either the configuration in 'application-ids.yml' or 'application-pdf-renderer.yml'.
Some settings are the same for both cases.
1.1. Common Settings
The default port for Rendering Service is 8880. Change it to for example 8881 with this setting:
server:
port: 8881
The connection to the pubserver is controlled by the following settings:
priint:
app-name: "renderingservice1"
comet:
bridge:
# Comet-bridge url/user/password are used to make the rendering-server (PDF Renderer or Adobe InDesign Server) connect to the pubserver.
# Please remember that the URL provided here needs to be resolvable by the rendering-server from its machine!
url: http://localhost:40082/CometBridge/Comet3Service
user: admin
password: somePassw0rd
# List of comma-separated project identifiers. Provide all projects you expect this rendering-service to process tasks for.
# This list is used on application startup to connect to comet bridge on pubserver. A connection is created for each project.
# That way you can get instant feedback if the connection fails, the rendering-service does not need to wait for a first task to arrive.
# Warnings are issued to logs if tasks from projects not listed here arrive as the application tries to recover and provide
# additional connections in such cases. It is best however to list the projects here in advance and keep this list up-to-date.
projects: DefaultProject,someOtherProject
planner-engine:
url: http://localhost:40080/PlannerEngine/api
# The user added here needs to be assigned to or have access to projects this rendering-service will process. Make sure you either
# explicitly configure this account to take part in projects or grant it a role that enables it to access any project.
user: admin
password: somePlannerEnginePassw0rd
# how often will the rendering-service report to pubserver
heartbeat-idle-millis: 60000
heartbeat-busy-millis: 5000
# Settings below control the HTTP client used to connect to the planner-engine. Default timeouts are 30s each.
connect-timeout-millis: 30000
read-timeout-millis: 30000
write-timeout-millis: 30000
If your installation uses different settings for host, port, user, password or project, please change them. Use localhost in the urls, if your rendering service is installed on the same host as the pubserver.
The connection to priint-bpm is controlled by the following settings:
priint:
camunda:
externalclient:
base-url: http://localhost:8888/engine-rest/
password: someCamundaPassw0rd
user: admin
backoff-time: 600
# Leave empty to handle all processes. Provide a comma-separated list of process keys to process only those processes.
handled-processes:
For object storage, the settings need to be configured:
priint:
objectstore:
minio:
# minio server adress and port
endpoint: http://127.0.0.1:9000
# minio server user
access-key: minioadmin
# minio server password
secret-key: someMinioPassw0rd
# region to use for configuring the S3-compatible-service client
region: us-east-1
If your installation uses different settings for host, port, user or password, please change them.
Rendering settings are controlled using the following settings:
priint:
rendering:
# This determines the resolution of preview files generated along with document metadata during rendering
document_preview_resolution: 120.0
# This is the time needed for Adobe InDesign Server lock files to disappear once a document gets unlocked
document_closing_timeout_seconds: 10
# The auto-conversion flags can be either true or false (and are treated as true if they are not provided).
# If false, no conversion will take place when trying to open a document.
# This is used for regular document opening:
rendered_document_auto_conversion: true
# Another auto-conversion flag. This determines, if auto-conversion should be turned on for grid element preview document openings.
preview_document_template_auto_conversion: true
1.2. Special Settings
Some settings are unique between Adobe InDesign Server® and priint:pdf renderer.
1.2.1. Settings for Adobe InDesign Server®
If your pubserver uses Adobe InDesign Server®, the following setting is needed (and already in application-ids.yml):
spring:
profiles:
active: indesign-server
No further changes in application-ids.yml are needed. You can, however, set the logging configuration of the InDesign Instances this rendering-service connects to:
priint:
indesign:
# This whole section is only used if working with Adobe InDesign Server, not the PDF Renderer.
# The following allows the rendering-service to override logging configuration of the rendering-server when connecting to each instance.
# All logging properties below need to be set and non-blank (even if the threshold_level is set to OFF)
# for the configuration to be considered complete and sent over to the rendering-server.
logging:
# Minimal log command level that should make it to the log files. Type OFF to set InDesign Server logging off.
# Other allowed values include: ERROR, WARN, INFO, DEBUG, TRACE.
threshold_level: TRACE
# File path perceived by the rendering-server where the log files should be placed.
# Use $INSTANCE_NAME as a placeholder for instance ids, eg. C:/comet/log/testlog-$INSTANCE_NAME.log
file_pattern: C:/comet/log/testlog-$INSTANCE_NAME.log
# Logback style encoder-pattern to format each log entry, eg. "%d %p %c{1} [%t] %m%n"
message_pattern: "%d %p %c{1} [%t] %m%n"
1.2.2. Settings for priint:pdf renderer
If your pubserver uses priint:pdf renderer, the following settings are used:
priint:
pdfrenderer:
# this whole section is only needed if working with a PDF Renderer, not the Adobe InDesign Server
pdfr_native_library_path: C:/PubServer460/rendering-worker-service/native/win
# config folder with pdf profiles, color profiles and licences
pdfr_config_path: C:/PubServer460/rendering-worker-service/config
# this is where the rendering service jar is placed
installation_path: C:/PubServer460/rendering-worker-service
spring:
profiles:
active: pdf-renderer
Please adjust the three paths to your installation folder.
Detailed description of external properties overrides available can be found here.
2. Observability
2.1 Logging
You can configure logback to output logs as desired. When defining your own application-....yml, just define a pointer to logback config file like this:
logging:
config: your-logback-file.xml
Then create your-logback-file.xml next to your jar and application....yml. Example configuration you might use as a start:
<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="30 seconds">
<include resource="org/springframework/boot/logging/logback/defaults.xml"/>
<include resource="org/springframework/boot/logging/logback/console-appender.xml"/>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>rendering-service.log</file>
<encoder>
<pattern>%d{HH:mm:ss.SSS}|%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
</encoder>
</appender>
<!-- Appenders and loggers below should only be set when working with the PDF renderer -->
<appender name="PDF-RENDERER-INSTANCE-1" class="ch.qos.logback.core.FileAppender">
<file>C:\comet\log\pdf-renderer-1.log</file>
<encoder>
<pattern>%d %p %c{1} [%t] %m%n</pattern>
</encoder>
</appender>
<logger name="com.priint.comet.renderer.pdf.Instance1" level="INFO" additivity="false">
<appender-ref ref="PDF-RENDERER-INSTANCE-1"/>
</logger>
<appender name="PDF-RENDERER-INSTANCE-2" class="ch.qos.logback.core.FileAppender">
<file>C:\comet\log\pdf-renderer-2.log</file>
<encoder>
<pattern>%d %p %c{1} [%t] %m%n</pattern>
</encoder>
</appender>
<logger name="com.priint.comet.renderer.pdf.Instance2" level="INFO" additivity="false">
<appender-ref ref="PDF-RENDERER-INSTANCE-2"/>
</logger>
<appender name="PDF-RENDERER-INSTANCE-3" class="ch.qos.logback.core.FileAppender">
<file>C:\comet\log\pdf-renderer-3.log</file>
<encoder>
<pattern>%d %p %c{1} [%t] %m%n</pattern>
</encoder>
</appender>
<logger name="com.priint.comet.renderer.pdf.Instance3" level="INFO" additivity="false">
<appender-ref ref="PDF-RENDERER-INSTANCE-3"/>
</logger>
<appender name="PDF-RENDERER-INSTANCE-4" class="ch.qos.logback.core.FileAppender">
<file>C:\comet\log\pdf-renderer-4.log</file>
<encoder>
<pattern>%d %p %c{1} [%t] %m%n</pattern>
</encoder>
</appender>
<logger name="com.priint.comet.renderer.pdf.Instance4" level="INFO" additivity="false">
<appender-ref ref="PDF-RENDERER-INSTANCE-4"/>
</logger>
<!-- END of PDF renderer appenders and loggers -->
<root level="INFO">
<appender-ref ref="CONSOLE"/>
<appender-ref ref="FILE"/>
</root>
<logger name="com.priint" level="INFO"/>
</configuration>
2.2 Health checks and metrics
Health and separate readiness and liveness endpoints can be activated by adding the following lines to application/yml:
management:
endpoint:
health:
show-details: ALWAYS
probes:
enabled: true
health:
livenessstate:
enabled: true
readinessstate:
enabled: true
endpoints:
web.exposure.include: health
Following endpoints will become accessible by HTTP GET at runtime:
http://your-host:your-port/actuator/healthhttp://your-host:your-port/actuator/health/readinesshttp://your-host:your-port/actuator/health/liveness
To expose metrics in prometheus format add prometheus to the list of exposed endpoints and enable metrics collection.
management:
endpoints:
web.exposure.include: ..., prometheus
For metrics configuration add metrics properties to application.yml and adjust them to your needs. For example, to enable percentiles histogram for the timer named "rendering.service.timer" add the following lines:
management:
metrics:
distribution:
percentiles-histogram:
"rendering.service.timer": true
# minimum-expected-value:
# "rendering.service.timer": 100
# maximum-expected-value:
# "rendering.service.timer": 10000
Following endpoint will become accessible by HTTP GET at runtime:
http://your-host:your-port/actuator/prometheus
3. Configuring worker properties
You are not done yet, the workers are configured in a second file, either workers-config-ids.json or workers-config-pdf.json. These are not YML, but JSON files.
Use workers-config-ids.json for Adobe InDesign Server®:
{
"workerTypes" : [
{
"workerType": "InDesignWorker",
"defaultWorkerConfig": {
"type": "InDesignWorker",
"topic": "priint-rendering",
"lockDuration": 60000,
"maxTasks": 1,
"usePriority": true
}
}
],
"applications" : [
{
"applicationName" : "renderingservice1",
"workersPools" : [
{
"type" : "InDesignWorker",
"workersConfig" : [
{
"type" : "InDesignWorker",
"indesignServer": "http://localhost:4712"
},
{
"type" : "InDesignWorker",
"indesignServer": "http://localhost:4713"
},
{
"type" : "InDesignWorker",
"indesignServer": "http://localhost:4714"
}
]
}
]
}
]
}
Add as many workersConfig as there are Adobe InDesign Server® instances reserved for rendering workers. Please note, that an instance can be used either for a rendering worker or for the old comet server. If the same instance is used from both services, a lot of strange problems will occur. Adjust the URL of the instance to your configuration. The port must be the port set by the instance option -cometport on the instance.
Use workers-config-pdf.json for priint:pdf renderer:
{
"workerTypes" : [
{
"workerType": "PdfRenderingWorker",
"defaultWorkerConfig": {
"type": "PdfRenderingWorker",
"topic": "priint-rendering",
"lockDuration": 60000,
"maxTasks": 1,
"usePriority": true
},
"defaultWorkersCount": 4,
"maxWorkersCount" : 4
}
],
"applications" : [
{
"applicationName" : "renderingservice1",
"workersPools" : [
{
"type" : "PdfRenderingWorker"
}
]
}
]
}
No further changes in workers-config-pdf.json are needed.
3.1 Workers Configuration File Structure
This section describes the fields found in the worker config files in the order of their appearance. A description of the idea behind the format of this config is also provided along with detailed explanations of the config values.
3.1.1 Fields in worker configuration file
Here is a description of the fields in the order they appear in the file
| Field name | Mandatory | Values | Description | ||
| 1st level | 2nd level | 3rd level | |||
| workerTypes | required | list of worker types - for now only 1 is used at once | |||
| workerType | required | PdfRenderingWorker, InDesignRenderingWorker | |||
| defaultWorkerConfig | optional | set | It is a sub-set of properties from worker-specific configuration which should be common for all the worker instances. These values will be pre-set for every worker in every application (but can be potentially overriden on the lower lever) - for the structure refer to section 3.1.3 | ||
| defaultWorkersCount | optional | number | if a worker doesn't require low level config settings (like Adobe InDesign Server® url which has to be different for each worker) you can just specify default number of its instances. This value can be also overriden on lower levels. | ||
| maxWorkersCount | optional | number | maximum number of workers of a given type. | ||
| applications | required | ||||
| applicationName | required | string | it is matched from priint.app-name application property | ||
| workerPools | required | list of worker pools - one for each worker type working on a given machine. When one type is used then would be only 1 entry for every application | |||
| type | required | must be set the same as workerType | the only required field for a worker pool allowing us to link it to a given workerType - must be equal to workerType value | ||
| defaultPoolLevelConfig | optional - not used | allows to define worker specific configuration common for all the workers in the pool. Specified values will potentially override the values from the type level and can be still overriden on the concrete worker level. For the structure refer to section 3.1.3 | |||
| workerConfigs | optional | one of the possibilities to specify concrete worker instances - there will be as many workers as entries of this array. It allows you to define different configuration for every worker. Each config is a sub-set of properties from worker-specific configuration - for the structure refer to section 3.1.3 | |||
3.1.2. Worker types
In the workerTypes field is defined only the type of the worker. No worker will be started if only this field is set. It is just the type definition (like a class without an object instance). Certain worker behavior (rendering through Adobe InDesign Server® or priint:pdf renderer through a pdf library) is associated with a given worker type.
Only 2 types are available in Worker Service: PdfRenderingWorker and InDesignRenderingWorker - each of them requires different configuration properties.
3.1.3. Worker specific configuration
There is a fixed set of configuration properties for every worker type. Each configuration consists of common properties and custom properties.
3.1.3.1 Common properties
Common properties are the same for all the types and for the moment we use the following ones: type, topic, lockDuration, maxTasks, usePriority. These fields are used to configure and initialize the Camunda client. Their meaning is the following:
| Property | Required | Value | Description |
|---|---|---|---|
| type | required | PdfRenderingWorker, InDesignRenderingWorker | workerType is required for every config property definition - it must be the same as workerType field of a given worker |
| topic | required | priint-rendering | the camunda topic name for a given worker type - this field shouldn't be modified |
| lockDuration | optional | integer | defines (in millis) for how long the camunda will lock a given camunda task for processing by a given worker. After this time passes the given task may be unlocked and given to another worker. If 80% of the lock duration passed and the task is still being processed, a watchdog thread will attempt to prolong the lock. We therefore recommend to either leave this property out (for a default of 60000 ms to be used) or set it to at least 10000 ms. A warning will be printed in the logs if you specify a smaller value. |
| maxTasks | optional | integer | defines how many tasks should be fetched at once when accessing Camunda. Typically, equal to 1 when tasks should be fetched one by one. We don't recommend changing this value unless you need to process big amount of short-living tasks and fetching them one by one would require too many requests and would be too slow. |
| usePriority | optional | boolean | true by default - if set to false camunda will ignore task priorities when fetching tasks |
3.1.3.2. Custom properties
Custom fields are exclusive for a given worker type and are typically related to its specialization. For example InDesignRenderingWorker uses obligatory indesignServer property. Here is full set of properties for InDesignRenderingWorker:
{
"type": "PdfRenderingWorker",
"topic": "priint-rendering",
"lockDuration": 60000,
"maxTasks": 1,
"usePriority": true,
"indesignServer" : "http://localhost:4714"
}
3.1.3.3 Configuration levels
As you may have noticed the files are named global-xxx-workers-config.json. Why do we use global in name? Because the structure is prepared to manage configuration of workers on multiple machines in one central place. Thanks to that you can define the worker properties on various levels:
workerTypeapplication- machine on which it is working- concrete
workerson a given machine which live insideworkerPools- one for eachworkerType
On each level you can define a sub-set of all the configuration properties for a given worker type. At the same time when the application starts, it always checks the whole file by for example checking if properties are globally unique and obligatory values are present. To take the advantage of such validation define the same file for all the applications (machines) running Worker Services and map to the proper application level configuration by setting the appropriate priint.app-name.
4. Running the Application
On Windows as user application start a cmd, cd to the rendering-worker-service folder.
If your pubserver uses an Adobe InDesign Server®, execute:
start-rendering-service-ids.bat
If your pubserver uses a priint:pdf renderer, execute:
start-rendering-service-pdf.bat
You can create a Windows Service instead. The file worker-service-4.6.xml controls the features of the service.
<service>
<id>rendering-worker-service-4.6</id>
<name>rendering-worker-service-4.6</name>
<description>Rendering Worker Service for priint:suite 4.6</description>
<executable>C:\PubServer460\java\jdk17\bin\java</executable>
<arguments>-jar "%BASE%\rendering-service-4.6.jar" --spring.config.additional-location=file:"%BASE%\application-pdf.yml" --workers.config="%BASE%\workers-config-pdf.json"</arguments>
<logmode>rotate</logmode>
</service>
Please adjust the path to java according to your installation path. If your pubserver uses an Adobe InDesign Server®, change <arguments>...</arguments> like that:
<arguments>-jar "%BASE%\rendering-service-4.6.jar" --spring.config.additional-location=file:"%BASE%\application-ids.yml" --workers.config="%BASE%\workers-config-ids.json"</arguments>
Then start an administrator cmd, cd to the rendering-worker-service folder and execute:
worker-service-4.6.exe install
When your service was created, do not forget to start it.
4.1. Check Status of Rendering Workers
To check the status of the configured rendering workers (e.g. InDesign Server Instances) open Worker Status Page
http://your-host:your-port/workers/status