Well shuck my britches and hold those taters!
Once again reality has an interesting way of confounding us.
Did you know that crow is actually rather tasty, when you
douse it with Dr. John's Caribbean Fire Juice?
I have reconsidered the need for a 'cache status indicator'
now that I have done some tests with the LPRng 'status cache'
implemented.
Here is what LPRng is now doing:
When a request for status comes in, it uses cached status as
much as possible. The overhead to get the cache status is:
a) fork
b) cd /spooldir
c) open small cache tag file and read
d) stat some status files for timestamps
e) if the status has changed
GRINDER GRINDER... and produce
new status and put in cache file.
f) open cache status file
read and dump status back at requestor
Now lets see what the steps would be if we used the method of
asking the LPD server for the 'status cache flag', and then
getting the status only if itw was stale.
If the cache was not stale, then we would do a-d, and then use
OUR LOCALLY STORED CACHED STATUS on the Samba server. So we would
be storing the status information TWICE. Once in the Samba server,
and once in the LPQ cache.
Worse yet, if the cache was stale this require us to
a) connect to the LPD server twice
b) Have the server fork a process twice
c) send request and get a reply twice.
Now if one reply is very short, and the other is quite long...
then we have a winner.
HOW LONG IS STATUS?
On my test system here with 4 queues, and, I must admit,
short status:
> lpq -a |wc
19 106 871
Here is the status:
Printer: lw4@h4 'Hp : Laserwriter' (printing disabled)
Queue: 1 printable job
Server: no server active
Status: removing job 'papowell@h4+659' - JREMOVE at 11:37:45.069
Filter_status: (of) FD 1 IS CLOSED!!! LOGIC ERROR IN CODE!!! at 11:35:10.014
Rank Owner/ID Class Job Files Size Time
1 papowell@h4+579 A 579 /tmp/hi 3 13:04:11
Printer: lw8000@h4
Queue: no printable jobs in queue
Status: job 'papowell@patrick2+8' removed at 14:39:54.063
Filter_status: done at 14:39:54.040
Printer: tcubed@h4 'Tcubed Hp Laserwriter'
Queue: no printable jobs in queue
Status: job 'darin@darin+363' removed at 10:28:49.495
Filter_status: done at 10:28:49.479
Printer: raster@h4
Queue: no printable jobs in queue
Status: job 'root@h4+901' removed at 11:50:17.055
Filter_status: done at 09:44:36.712
If I do 'lpq -s' I get:
> lpq -s -a
4 12 68
lw4@h4 1 job
lw8000@h4 0 jobs
tcubed@h4 0 jobs
raster@h4 0 jobs
If I do the 'checksum ' thing I would have about a 32 byte (MD5 checksum)
value returned...
I hate to say this, but I think that the overhead of getting the
status twice, the load on the system, etc., would actually cause
status to be delivered SLOWER when you need it, and virutally
no difference at all for short status.
This sounds stupid, but it is true for SMALL SHORT STATUS REPORTS.
I just see no major advantage in implementing the 'cache flag' apparatus.
Sooo... we go back to the original design and method:
Just use the 'lpq' command to get the status.
Now, there is a way to make this VERY lightweight on the Samba side:
Open a connection and send the request directly to the server.
Lets see: we use the following as a test case:
#!/bin/sh
printf "\004t1 -lines=4\n" |nc -w 2 localhost 2000
The programmatic would be almost as brutal:
socket/connect write("\004...") while(read()) print status
Lets see what we get for usage:
h4: {251} % time /tmp/status
Printer: t1@h4 'Test Printer : 1'
Queue: no printable jobs in queue
Status: finished 'papowell@h4+219', status 'JSUCC' at 08:17:18.967
Status: subserver pid 21397 exit status 'JSUCC' at 08:17:18.969
Status: [EMAIL PROTECTED]: job 'papowell@h4+219' printed at 08:17:18.972
Status: job 'papowell@h4+219' removed at 08:17:18.981
0.0u 0.0s 0:00.04 0.0% 0+0k 0+1io 0pf+0w
Note that you could do this in a thread, you would not need to
fork/exec.
Now I am not saying that this is a good solution, just that
you could do it.
I am ready to eat crow on this one. But at least status reporting is now
BLAZING fast.
Patrick
-----------------------------------------------------------------------------
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body. For the impatient,
to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED]
with: | example:
subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
If you have major problems, send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------
