1 Reply Latest reply on Mar 11, 2016 8:46 AM by Scott Olswold

    Blueprint Disaster Recovery by CNAME and job list retrieval delays

    Nikolay Karetnikov Navigator

      Hello!

      Please consider the following scenario

       

      A collector prn01.mydomain.com is used for a site. For a disaster recovery option another collector is installed - prn02.mydomain.com. A CName record is created with the name prn21.mydomain.com and points to prn01.mydomain.com. Now, we imitate the first collector's failure as if a disaster happened. The prn01 is shutdown, prn21.mydomain.com now points to prn02.mydomain.com.

      When a user iprintrarely@mydomain.com enters his PIN code on a terminal the message "you have no documents" gets displayed as usual, but when another user iprintoften@mydomain.com enters his PIN code on a terminal the message "you have no documents" appear only after about 30 seconds. The difference between those users is that the later has unreleased jobs on the failed collector.

      AFAIU this happens because the prn02 attemtps to reach the prn01 for a list of jobs and waits kind of network timeouts until the prn01's response. If that is the case can those timeouts be controlled anyhow? This particular customer implemented a very short period of session on all of theirs terminals (just 15 second), so unless one's constantly touching a screen, MFDs return to the welcome page on its touchscreen and never display the "no documents" message

        • Re: Blueprint Disaster Recovery by CNAME and job list retrieval delays
          Scott Olswold Guide

          Nikolay,

           

          You are correct that the cause for the behavior you're seeing is due to the "prn01" server being down during the "list jobs for print station" event. A user's server activity is remembered for 5 days (by default; you can change that behavior by modifying each server's <UserPrintActivityLifetime> value in the GlobalConfig.xml file). This is done to help keep the system resilient in the event that the Analyst (who maintains all user print notifications from its Collectors in its database) is unreachable.The time-out for the "list jobs" call to another Collector is, as you observed, 30 seconds. I do not know of any way to decrease this timer.

           

          On another related topic: 15 seconds is a very slim time to react. In light of the response times when a failover must occur, I would suggest pushing this to a 35 second timer.

           

          Scott