New Release: Waarp R66 3.4.0

Tags: #<Tag:0x00000c6ee8dc68c0> #<Tag:0x00000c6ee8dc6690>

Release Notes

Version 3.4.0 of Waarp R66 is the second major iteration of the application this year. It adds two new features:

  • support of ICAP protocol to send files to compatible servers and trigger verifications
  • transfers are now associated to a unique identifier which is kept between rebounds (followId)

It also contains several enhancements, fixes, and resources optimization.

ICAP Support

A new task named ICAP has been added to communicate with an ICAP-compatible server that implement RFC 3507.
If (and when) this task is set as pre- or post-transfer processing, the transferred file is sent to an ICAP service using a RESPMOD command in order to obtain a validation for this file.

This task can be used, for example, to run an anti virus check on the file, of for any other security control or feature provided by the ICAP service.

See the documentation (French) for more information.

follow Identifier

This new identifier offers a fine-grained way to follow transfers across rebounds. This feature adds a unique identifier in the transfer information (e.g.: {"follow": uniqueNumber}) for the first transfer of a file, and every subsequent re-transfer will keep this value.

This option is enabled by default. If you do not want to use follow identifiers, the argument -nofollow has been added to the send commands.

The REST v2 API integrates the follow identifier as a transfer filter (GET /v2/transfers/?followId=number). As number can be a long integer, it is preferable to handle it as a string.

Log Noise Reduction During Startup

The initialization of the logging library can generate some logs on the standard output during the application startup. Those can be silenced, keeping only warnings and errors.

To do so, add the following line to your logback.xml files:

  class="org.waarp.common.logging.PrintOnlyWarningLogbackStatusListener" />

Changes in Default Configuration

In order to optimize data transfer and the use of system resources, the default value of some configuration options have been changed:

  • The default global bandwidth limit (option globallimit) has been raised to 100 Gbps.
  • The default session bandwidth limit (option sessionlimit) has been raised to 1 Gbps.
  • The maximal amount of RAM used by WEB and REST services has been lowered to 1 GB (it was 4GB).

Those modifications come with numerous other optimizations in RAM usage.

List of Changes

New Features

  • Transfers are assigned a unique follow identifier
  • The REST v2 API has an option to filter transfers by follow identifier
  • ICAP Support


  • Default bandwidth limits have been increased
  • Default RAM used by HTTP and REST services have been decreased
  • RAM usage for simple clients has been decreased


  • Possibility to silence the logs emitted by the initialization of the logging library
  • If no -Xms argument is set when the JVM starts, the JVM Default value is used (usually 4GB)
  • File filtering with regular expressions in the file watcher now works as expected (it was impossible to filter only filenames in a subdirectory)
  • Some commands were not working anymore because of a bug in log handling
  • Upgrade of external dependencies


This new version is fully-compatible with 3.x versions and does not require any additional step to upgrade.

The standard procedure (French) can be followed.