Scalable RIP Limitations

This page applies to Harlequin v13.1r0 and later; and to Harlequin Core but not Harlequin MultiRIP

These options are currently not supported when using HHR in a Scalable RIP fashion but do continue to work as normal for using a single HHR RIP instance.

• When invoking the Scalable RIP (-nrips), you must use the -m option. This specifies the memory (in MiB) to be used among all the farm RIP instances. For example, the use of -nrips 4 -m 3000 would split 3000 MiB among four farm RIPs, giving 750 MiB to each. Memory requirements vary, but a good starting point for evaluation is to assign 3000 MiB to each RIP. This would mean for two RIPs using -m 6000 and for four RIPs -m 12000 – assuming there is sufficient memory in the system.
• -o is not supported. For a Scalable RIP, the -o command-line argument will not override /PageBufferType in the pagedevice; set it in your TestConfig instead.
• -s is not supported. For a Scalable RIP, the -s command-line argument will not override /OutputTarget in the pagedevice; set it in your TestConfig instead.
• Only one Scalable RIP can be run on a single machine (i.e., one controller RIP and zero or more farm RIPs); this is because the controlling RIP binds to a well-known port and only one process can listen on this port.
• When using a Multi-Server Scalable RIP, the only supported configuration is for all servers to be running on the same operating system.
• Use of recombine will result in the job being processed by a single RIP. When this happens the message: "Scalable RIP using recombine job using one RIP" will appear in the Scalable RIP monitor. (Recombine is deprecated in Harlequin 13 and will be removed in v14).