Configuration

Antivirus Settings

Ensure that the antivirus does not scan the ARender Rendition folder and sub-folders below.

Cache Management

Local vs Shared

ARender uses Hazelcast to manage its rendition cache.

Local Cache

By default, each Rendition instance maintains its own local cache, meaning cached documents are not shared across instances.

Shared Cache

With an NFS (Network File System) shared across all Rendition servers and properly configured Hazelcast, cache data can be shared among instances.

Benefits of Shared Cache:

• Improved Redundancy: If one instance fails, others can still access cached documents without needing to re-fetch them.
• Enhanced Performance: Reduces retrieval time as previously cached documents remain available to all instances, enhancing speed and reliability in multi-instance environments.

For comprehensive Hazelcast details, refer to Hazelcast documentation.

Default Hazelcast Configuration

The configuration file (hazelcast.yaml) is located within the RenditionEngine resources.

The path to find the configuration is modules/RenditionEngine/rendition-engine-micro-service-2023.5.0.jar/BOOT-INF/classes/hazelcast.yaml.

hazelcast:
  map:
    documentAccessors:
      max-idle-seconds: 3600
      eviction:
        eviction-policy: NONE
        max-size-policy: PER_NODE
        size: 5
  network:
    join:
      auto-detection:
        enabled: false
    rest-api:
      enabled: true
      endpoint-groups:
        CLUSTER_READ:
          enabled: true
        HEALTH_CHECK:
          enabled: true
        WAN:
          enabled: true
        DATA:
          enabled: true

Cleaning the temporary directory at startup

While Hazelcast evicts entries from the cache, you can also configure cache directory cleanup at application startup using:

Configuration

default.document.path.startup.clear=true

Adjustable Cleanup Timing:

The default behavior is the deletion of all folders created more than a day ago.

Adjust this value by modifying the configuration below:

temp:
  files:
    folder: ../../tmp/
    house-keeping:
      expiration:
        time: 1
        unit: DAYS

rest-api

The REST API is enabled by default with enabled: true. Endpoint groups can be customized for use; details are available in the Hazelcast documentation.

Default Enabled Endpoints

This section allows you to define the endpoint groups that can be used with the REST API. You can find more details on related Hazelcast documentation.

CLUSTER_READ

Allows access to the following endpoints :

• /hazelcast/rest/cluster
• /hazelcast/rest/management/cluster/state
• /hazelcast/rest/license (GET)
• /hazelcast/rest/management/cluster/version (GET)
• /hazelcast/rest/management/cluster/nodes
• /hazelcast/rest/instance
• /hazelcast/rest/log-level (GET)

HEALTH_CHECK

Allows access to the following endpoints :

• /hazelcast/health/node-state
• /hazelcast/health/cluster-state
• /hazelcast/health/cluster-safe
• /hazelcast/health/migration-queue-size
• /hazelcast/health/cluster-size
• /hazelcast/health/ready

Customizing Hazelcast Configuration

To customize the Hazelcast configuration, create your own hazelcast.yaml file and copy the configuration from the file ARender-Rendition-2023.5.0\modules\RenditionEngine\rendition-engine-micro-service-2023.5.0.jar\BOOT-INF\classes\hazelcast.yaml.

After making your own configuration file, modify the custom-setenv.bat (or the custom-setenv.sh) file to specify the new file path.

Add the following argument to the list of JVM arguments: -Dhazelcast.config=path_to_your_file.

If the path specified is hazelcast.yaml then the file should be placed into ARender-Rendition-2023.5.0\modules\RenditionEngine.

set ARENDER_BROKER_JVM_ARGS=-Djava.net.preferIPv4Stack=true -Djava.net.preferIPv6Addresses=false -Dloader.path="client_libs/" -Dfile.encoding=UTF-8 -Dhazelcast.config=hazelcast.yaml

Cache Directory Settings

For Separate Cache Directories Between Multiple Renditions

Disable Auto-Detection

Make sure the auto-detection property is disabled (this is the default setting).

Web-UI Configuration

Specify each Rendition host in the Web-UI server configuration. The distribution will be managed based on the health of the Renditions.

Configuration details can be found on the dedicated page.

For Shared Cache Directories Among Several Renditions

Hazelcast port opening

By default, Hazelcast uses port 5701. Ensure this port is open on all Rendition servers for communication.

Enable Auto-Detection

Activate auto-detection to allow Hazelcast to recognize all Rendition instances.

Rendition Instance Locations

Ensure all Rendition instances are on the same subnet for cache sharing.

Configure shared directory

For using Hazelcast with multiple Rendition instances and a shared directory, the directory must be on NFS.

Each microservice needs to specify the location of the shared cache directory in the application.yaml file.

temp:
  files:
    folder: ../../tmp/

shared-files:
  sharedPath: ../../tmp/

shared-files:
  sharedPath: ../../tmp/

tmp:
  dir:
    doc: ../../tmp/

shared-files:
  sharedPath: ../../tmp/

Load balancer

Configure the Web-UI with Load balancer

This configuration is possible only when the cache is shared across multiple Rendition instances, see:

• For Shared Cache Directories Among Several Renditions,
• Shared Cache.

If a Load Balancer is present between the Web-UI and Renditions, specify the Load Balancer’s host in the Web-UI server configuration instead of listing individual Rendition hosts.

arender.server.rendition.hosts=LOAD_BALANCER_HOST

Configure the Web-UI without Load balancer

If there’s no Load Balancer, specify each Rendition host in the Web-UI server configuration. The distribution will be managed according to the Renditions' health.

Detailed configuration can be found on the dedicated page.

Network File System (NFS) Configuration

This configuration is required only when the cache is shared across multiple Rendition instances, see:

• For Shared Cache Directories Among Several Renditions,
• Shared Cache.

Proper NFS configuration is crucial for synchronizing different nodes. Two primary optimizations can cause NFS clients to become out of sync:

• Asynchronous Writing (default): This option is set by default.
• Local Read Cache: Options for NFS should include the below configuration to ensure client synchronization:

sync,noac,lookupcache=none

Refer to the following resources for more information:

nfs(5) - Linux man page 10.3
NFS Red Hat Enterprise Linux 6

Office backend selection (Optional)

ARender offers three configurations for converting Office documents to PDF, each with unique strengths and weaknesses:

• LibreOffice
  • Description: Converts Microsoft, OpenOffice, and LibreOffice documents.
  • Pros: Free and open-source, broad file compatibility.
  • Cons: Conversion quality may vary on complex documents; limited support for issue resolution.
• Microsoft Office
  • Description: Converts Microsoft, OpenOffice, and LibreOffice documents.
  • Pros: Excellent conversion quality, especially for complex Office files.
  • Cons: Requires a Microsoft Office license, adding cost.
• DirectOffice (Recommended for Premium experience)
  • Description: Converts Microsoft documents; relies on LibreOffice for OpenOffice and LibreOffice files.
  • Pros: Fast, high-quality conversion; quick issue resolution through Uxopian support.
  • Added Value: Ideal for businesses seeking consistent quality and reliable technical support.

mimetype:
  support:
    msoffice: "${mime.type.msoffice.publisher},${mime.type.msoffice.visio},${mime.type.msoffice.rtf},${mime.type.msoffice.project}"
    libreoffice: "${mime.type.libreoffice.text},${mime.type.libreoffice.sheet},${mime.type.libreoffice.presentation},${mime.type.libreoffice.graphics}"    
    directoffice: "${mime.type.msoffice.word},${mime.type.msoffice.excel},${mime.type.msoffice.powerpoint}"

C:\Windows\System32\config\systemprofile\Desktop
C:\Windows\SysWOW64\config\systemprofile\Desktop

PDFOwl: a document renderer alternative

Description

We have introduced PDFOwl as an alternative to the standard JNIPdfEngine for document rendering.

In the existing document-renderer setup, errors within the native library can cause the entire application to crash, as these issues occur at a low level and cannot be intercepted at the application level.

To improve stability, PDFOwl employs a resilient approach that maintains performance while isolating errors. It manages rendering requests through sub-processes, allowing errors to be handled without affecting the main process.

Setup

• Navigate to: modules\RenditionEngine,
• Open or create the application.properties file,
• Add the following property:

micro-services.pdf-renderer=PDFOwl

Configurations

PDFOwl offers several configurable properties with default values listed below.

To update these properties:

• Navigate to: modules\PDFOwl,
• Open or create the application.properties file,
• Add the property and its value.

# PdfOwl binary path
pdfowl.path=pdfowl
# Timeout for pdfowl commands execution in milliseconds
pdfowl.client.watchdog=10000
# Timeout for idle pdfOwl clients in milliseconds
pdfowl.client.ttl=30000
# The memory limit used for a thread to work on a single document
pdfowl.memlimit.mb=1024