The Secure Release queue/service has no inherent limit (MobilePrint does; 50MB), but there are timers based on time to respond (printer to server), time to send (how long the job takes to get to the printer). But when one of those timers expires, the job is requeued, and that sounds like it isn't happening for you, so it probably isn't an expiring timer.
The transaction logs because Uniprint believes it is done with the job...in other words the printer ate the whole thing, and it is free to go about other business. So you have one of two (most likely) issues:
- The job is not successfully processing on the printer. Review the job log on the device to review disposition and make corrective action.
- The job is being held because some requested resource (paper size, paper tray) or configuration isn't available. The Xerox machines have a special place for those, too, within CentreWare Web, but I can't remember what it is.
I hope that this helps.
It does indeed help. I'm curious about the conditions at which Uniprint determines the printer is done with the job. Does it wait for a response from the printer to confirm this?
The Secure Release Service (SRS) determines "job is done" in one of two ways, based on your device connection type:
- LPR Connection. LPR/LPD is a classic TCP implementation, so there is incredible flow-control and checksum verification between both endpoints. In basic terms, the printer tells the server that it has received its last packet and the connection closes. In propeller-head mode, once the final [SYN] [SYN/ACK] [ACK] (synchronization/acknowledgement 3-way handshake) is passed between the server and printer, the TCP stack on the server sends a [FIN] (finished) TCP command to indicate session completion and an [RST] (reset) occurs to close the communications. When viewed through Wireshark, it is simply beautiful.
- RAW Connection. Sending data over port 9100 is one of the easiest things in the world: open a communication session, send the data, and then close the session. The receiver uses the "close session" packet as the sign-off and then prints what it has in the buffer. But it also poses some risks. The little "close session" command is usually in a small-size packet. Because data still has to be sent in packets, and packets can arrive out of order, if you have network issues during the communication...the sign-off can actually get there before the tail-end of the job data does. In most cases, this presents itself to the end user as "you get only part of your document." On some devices that might wind up failing the whole job (I don't have a lot of experience with Xerox; HP, Ricoh, Canon, Toshiba and Konica-Minolta all print what they have in buffer).
What did you find out about the missing jobs?
If I may "pop" in a couple comments to this discussion...
My experience is mostly with HP brand and a few (not many) Xerox units. From what I've seen with the few Xerox units I've worked with, the Xerox devices are almost identical handling LPR or RAW with the exception some Xerox units prefer a port such a "print" to be specified but may not require it. HP units favor RAW but will handle LPR well though LPR seems slower.
- LPR Connection. From my experience, there is very little to no "printer status" communication with LPR and aside from the "are you ready to receive" and "I'm done receiving" communications and reports only "Printer Error" nothing more if there is a problem. LPR is nearly a "blind dump" from the sender. The sender does not know the status of the printer outside of when asked if ready for data or done getting data. Should also note LPR is "FIFO" (First In, First Out) which means if you have 5 persons trying to print using LPR at the same time, the first one to make a connect to the server is allowed to deliver it's data and all the other have to wait one at a time. This isn't much of a problem with printers because they're only going to receive one job at a time anyway. If using LPR to connect systems to your Uniprint server, there you may see significant speed issues including connection time out.
- RAW Connection. In nearly all cases, from my experience RAW tends to be quicker, which may be partly due to having smaller header/footer data packets, and it may have higher data transfer rates (I haven't found anything to confirm that). RAW is more "robust" in it's communications and feedback with the printer's status which can be a good thing, but can also "bite" you by causing a printer to be detected as "not available" simply because someone opened a paper tray for a moment, after which there may be a couple moments to a few minutes before the printer is detected as "available" again, and this can result in frustrated users. Though at least it usually reports more data about what was detected as a problem. In places where frequent "not available" status is detected needlessly, I may switch the device in Uniprint to LPR just to decrease the false "not available" incidents. Otherwise, for the sake of speed and overall reliability, I default to RAW for most printers.
As for print job size, Scott is right, no real job size limit (except in MobilePrint) however in all practicality, the bigger the job the more likely there will be an error. In my opinion, 40 to 50 meg is big enough to be prone to problems and should be broke into smaller pieces or (in most cases) better optimized for printing before the user sends the job to be printed.. but few be the end users who will take the time to do that or even know they can do that extra effort. We have a location with a large printer in the classroom and we've elected to NOT put the large printer on our Uniprint system simply because we know the print jobs will be large (often 100 meg to 2 gig) and any "in the middle" processing will only get in the way.
My comments (if it's of any benefit to anyone).
- Paul L.
A couple of corrections:
- The "Device State Check" function available in Pharos Administrator is independent of the print protocol specified for the device, so I'm not sure what would be causing the difference in response (outside of explicit device support for the various error messages that can be emitted). Please note that a device's state is checked at the commencement of each print job, so if a user chooses the "Print All" option for 10 jobs, 10 checks will be performed, and this may not work well as some printers will either queue, or be slow to respond to, the state check request. Of course, outside of Pharos (IOW, using Microsoft's Standard TCP/IP port), your statement is highly accurate. I think that Microsoft has been trying to kill off LPR/LPD support in their OS for quite some time, but can't in order to support multi-platform environments.
- In a "direct print" scenario, SRS will only send one job at a time and queue the others based on arrival. This, too, is independent of the protocol being used for the device. In a "secure print" workflow, only one individual can be logged onto a device at any one time, so the queuing is less apparent.
- You are correct in that LPR/LPD is more "chatty" than is RAW. This is due to the lack of flow-control in RAW. However, this doesn't contribute to timeouts...a slow network or device will end up flummoxing RAW as well, but it may not be obvious because data is simply resent if there is a loss of packet synchronization/sequence.
And to further the comment on file size: At the very best, any network will only be able to manage data based on (roughly) the speed of the slowest component. A 100Mbps network device will, absent any overhead and line contention, be able to only manage 12.5MBps throughput (that's a best-case scenario). In Blueprint (where we can immediately manage the Send timer) the default "kill point" is 120 seconds. So if the job can't finish sending in 2 minutes, it gets requeued. At pure 12.5MBps, that's a 1.5GB file. And while some will stare in wonder at that number, in some environments, that's commonplace. At one location, due to a wonky switch, we ended up increasing the Send timer to an hour, as one type of job would routinely take 35 minutes just to spool to the printer (that was without any Pharos component in the middle!).
Thanks for all the detailed information. It appears that our jobs are being held in the Xerox jobs queue with a status "Waiting for authorization". We have seen this issue before, printing from a web application. We assumed it was particular to that report and suggested a workaround to the user. I'm not certain how the job was submitted yet. I've sent a message to the user to try to figure it out. I can update the thread with what I find, but this may be more of a Xerox problem than a Pharos problem. However, it would be more reassuring if Pharos had not charged the job.