5 Replies Latest reply on Apr 26, 2018 1:10 PM by Mark Royko

    Large job lists crashing OXPd

    Mark Royko Wayfarer

      we're running BPE 5.2, and this doesn't happen often, however we've run into a handful applications that will create a separate jobs when printing reports.  The result is hundreds if not over a thousand print jobs in the user's secure queue.   When our user walks up to the printer and hits secure release, 2 things can happen, the printer will crash and restart (sorry, I didn't capture the Error#), or the printer will display; "45.00.cb Error "Insufficient memory" occurred while communicating with http:\\<your servers URL here>".

       

      Currently we're left with having the user open scout on their workstation and delete jobs (much faster using scout than SRHT). and re-printing a smaller range of data in their reports, or giving them a separate queue that bypasses SRH entirely.

       

      Is there a way to limit the number of jobs sent to the terminal that I haven't found yet, or is this something that may need addressed in a future update?

        • Re: Large job lists crashing OXPd
          Scott Olswold Guide

          Mark,

           

          The issue at hand is that the HTML file being generated for the HP OXPd platform is too large for the HP's operating system to handle. The initial cause (too many jobs being generated) doesn't have a control: Microsoft does not impose any restriction on the number of jobs that can be printed, they can only restrict the available times to print a job and manipulate priority.

           

           

          Since you are using Blueprint 5.2, you could also use Pharos Print Center as a way to manage the printing.

           

          -Scott

            • Re: Large job lists crashing OXPd
              Mark Royko Wayfarer

              Right, but I'm not looking to limit the number of jobs submitted, only the number of jobs listed at the terminal.  I'd like to limit the number of jobs the server sends to the printer to present the user to say only the 1st 150 jobs.  The user than hits 'print all' and either the entire queue is printed (all 150+ jobs) or the next 150 jobs are listed when the queue is refreshed and they hit print all again till they empty their queue.

            • Re: Large job lists crashing OXPd
              tcampbell@pharos.com Tracker

              Hi Mark,

               

              I was able to reproduce the OXPd error on an older HP FutureSmart printer, an M4540.  This is one of HP's first generation of Futuresmart printers, and contains less available RAM than newer models.  I am also testing on a newer FutureSmart printer, an M577, and have not yet hit its limit.  (I've 800 jobs in queue!)  Its UI is pretty sluggish, but it's still alive and kicking.  :-)

               

              So, I'm wondering from where it would be best to approach this issue.  Various printers may behave differently due to variations in available RAM, etc.  I'm thinking that it may not be best to address this issue within the iMFP, but rather upstream of that within Blueprint itself.  For example, a setting that would limit the returned job list for any user to the first X jobs.  This would then have the benefit of addressing any potential concerns with any number of different makes & models of printers.

               

              Comments?

               

              Regards,

              Tim.

              1 of 1 people found this helpful
                • Re: Large job lists crashing OXPd
                  Mark Royko Wayfarer

                  That's right along the lines of what I was thinking..    the application service would have to limit to 150 jobs sent to the terminal.  user hit (print all) (maybe we need a 'delete all' button?) and 150 jobs print..  the list refreshes and the user is presented the next 150 jobs and repeats.   maybe 500 jobs would be a better number(?).