Choose your language

Choose your login

Support

How can we help?

Lightbulb icon
Lightbulb icon

Here’s your answer

Sources:

Lightbulb icon

Oops!

We currently don’t have an answer for this and our teams are working on resolving the issue. If you still need help,
User reading a resource

Popular resources

Conversation bubbles

Contact us

Behavior on server connection failures

This page applies to:

There are various scenarios where the users want to print their print jobs but the PaperCut NG/MF Application Server is unable to receive the information about the printing, including when:

  • The Application Server’s machine is being rebooted,

  • The network link is down between a secondary print server on a remote machine and the Application Server,

  • The administrator has decided to shutdown the Application Server for maintenance.

When this occurs PaperCut NG/MF must decide on how to handle the print job without communicating with the Application Server. The administrator can configure PaperCut NG/MF to handle new jobs in 3 ways:

  1. Allow new print jobs to print but do not log (default),

  2. Allow new print jobs to print and log after reconnection,

  3. Do not allow new print jobs to print but hold and wait for reconnection.

Each of these options offer different compromises, and the best option depends on the needs and priorities of a particular installation. For example, if it’s important to never interrupt printing then select options 1 or 2. If it’s important to strictly enforce quotas (i.e. allow the job to be canceled if they do not have enough quota) and it is acceptable to delay printing until the connection is reestablished then choose option 3. These options are discussed in detail below.

These configuration options are controlled under the Printers [select printer] > Failure Mode .

Failure mode settings

Mode 1: Allow new jobs to print but do not log

This is the default mode and allows jobs to print when the connection to the server is down (a “fail open” mode). The jobs printed during this period are not logged in the Application Server. Use this mode when:

  • It is important to not interrupt printing when outages occur,

  • The setup needs to be simple and easy to understand,

  • It is not important to log jobs printed during failures,

  • Strict quota enforcement is not required, Users will not be charged for printing that occurred during the outage.

Mode 2: Allow new jobs to print and log after reconnection

This mode allows jobs to print when the connection to the primary server is down, but when the connection is re-established these jobs are re-sent to the Application Server and logged (a “fail open” mode with re-send/offline mode). Use this mode when:

  • It is important to not interrupt printing when outages occur,

  • It is important to log/charge every job printed during failures,

  • Strict quota enforcement is less important. Users can use more credit than they have available.

In this failure mode the administrator can configure how these resent jobs are recorded in the job log:

  1. Leave the job information unchanged (i.e. log the job against the user that printed it),

  2. Change the recorded user to another nominated user,

  3. Change the charging of the print job to a nominated shared account.

The default reconnection option is 1, where logging and charging is done in the same way as if the recording was done live. The administrator might consider this unfair to charge the user during this failure time (as there were no warning popups or ways of telling that the user’s quota was reaching its limit). It might be more reasonable to use the reconnection options of 2 or 3. With option 2, the administrator can choose a new user, such as “AppServerDown” to record the job as and in this way completely divorce the user from jobs printed during the failure.

If the administrator wants to track who did the printing but thinks it is unfair to charge their personal account, then choose reconnection option 3, and a new shared account such as “AppServerDown”, or an account corresponding to the department owning the printer can be charged. Jobs are still recorded under the user’s name.

When the connection to the Application Server opens up again, the print jobs show up in the Application Server’s job log within a few minutes. They show up with a special status and icon in the job log (see figure below).

Mode 3: Do not allow new print jobs to print but hold and wait for reconnection

In this mode all jobs are held in the queue while the connection to the server is down (a “fail closed” mode). Once the connection to the server is reestablished the jobs are sent to the server and printing is processed as normal. Use this mode when:

  • Strict quota enforcement is required,

  • Secure Print Release or Find-me printing is used and jobs must not be printed until released by a user.

Failure mode settings on virtual queues

When using virtual queues and Find-me printing (see Find-Me printing and printer load balancing ), it is recommended to hold the all jobs and wait for reconnection when the server connection is down. By default, this setting is enforced by PaperCut to ensure the correct operation of the virtual queue.

If jobs are released from the virtual queue when the server connection is down, the jobs would be released to the configured printer (i.e. the configured printer port). If the queue is configured with a NULL port, the jobs are deleted. If configured for a non-existent printer (e.g. LPT1) then the jobs go into an error state. If configured for a real printer, the jobs are sent to the printer (contrary to the secure release / Find-me printing that the user expects). It is for these reasons that the failure mode on virtual queues is set to hold all jobs.

Some organizations prefer to have the virtual queue pointing to a real/physical printer so that if a failure occurs the jobs are printed. This is usually only acceptable if the organization is happy that users jobs be printed on a single queue (bypassing any secure print release function). To configure this, select the Override virtual queue failure mode check box; then select one of the alternative modes. This option is visible only on virtual queues.

Comments