[X2go-dev] [X2go-user] 10x printing speed increase for x2go printing

[Mike Gabriel]

Hi Phil,

On Di 12 Apr 2011 17:11:25 CEST "--[ UxBoD ]--" wrote:

> What is happening is that the Perl script, x2goprint, moves the PDF  
> from /var/spool/x2goprint into the users mounted spool directory and  
> then creates the .ready file. The x2goclient looks for any new files  
> in that directory and if it sees the .ready file it pops up the x2go  
> print dialogue window. Now, looking at the code it appears to remove  
> the file as-well; in 3.01-18 the pertinent code is in  
> onmainwindow_part4.cpp line 200.

in the pending patch for x2goprint I have changed the mechanism a  
little. The reason is that we have to presume in general that root  
cannot read-write to the user's home (e.g. if homes are on NFS3 with  
root-squashing, NFS4+Krb5, AFS+Krb5 etc.). So what I do is:

   o x2goprint scripts runs as root (sudo from x2goprint user)
   o copy print jobs to /tmp/spool_<user>/tmp
   o chown the files to <user>
   o su - to the user and move the print job directly into
     /tmp/spool_<user>/<session_id>
     ... instead of taking the detour via the home dir...

http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=16cdb70f5bbd129816bcebd4eb3a87a4b7ff71d7

> I am thinking this is a timing issue with respect to the .ready file  
> being written and the slot which monitors the local spool directory  
> firing off an event.

With PyHoca-GUI I have this strategy:

   o one printqueue thread is waiting for print jobs
   o if a job appears another thread is started that handles the print action
     (pdfview, pdfsave, print, ...)
   o the print action immediately creates a ,,local'' copy of the print job (to
     make sure it does not vanish while processing it)
   o whilst the first thread is counting till 60(secs) and then deletes the
     original set of job files
   o the print actions however have different ways of handling their  
local copy:

       o on Windows after having processed the print action task (e.g.  
opening a
         pdfviewer) there is a funtion that keeps checking if the file can
         be deleted. While it is locked by the file system, it will continue
         the deletion attempts till one of them is successful
       o on Linux I delete the files directly after I am sure that the job is
         processed (e.g. waiting long enough, testing for a print result, ...)

I guess that the creation of a local copy of a print job might be a  
solution...

Greets,
Mike




-- 

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20110412/6a3ba389/attachment.pgp>