[Zope] Zope lockups using an External Method

Adam Warner lists@consulting.net.nz
10 Sep 2001 13:23:16 +1200


On Mon, 2001-09-10 at 05:48, Dieter Maurer wrote:

Excellent help thank you Dieter.

> Object ids can have '.' in them. However, you cannot directly use such
> ids as names in Python expressions, you need to use
> "_.getitem('name.with.dot')".

Done.
 
>  > ....
>  > 	thefile=open('aaa123','w')
>  > 	thefile.write(inputdoc.data)
>  > 	thefile.close
> This is a bit dangerous, although probably not your problem...
> 
>    "OFS.Image.File.data" is a string, as long has the file
>    is sufficiently small. It becomes an object for larger files.
>    Use "str(inputdoc.data)" instead.

Done. The line now reads thefile.write(str(inputdoc.data))

>  > 	# Run wvPDF on the document
>  > 	os.system('wvPDF aaa123 aaa123.pdf')
>  > 
>  > 	return
> If you call the external method directly (from the Web)
> and you do not return a value, some browsers do not
> recognize the end of the request.
> Return, e.g. "Done".

Done. It reads Return 'Doc2PDF Completed'

>  > aaa123 is a word document. Can anyone see what has gone wrong?
> Not yet...
> 
>  > ...
>  > Before the external command wvPDF is run I can confirm that the word
>  > document (named aaa123) is sitting in the directory /var/tmp/xxxxxxxxx/.
>  > I can manually run wvPDF as user www-data.
> On the file created by the external method?

Exactly. I can su - www-data (to hopefully emulate the zope environment)
and then manually run "wvPDF aaa123.doc aaa123.pdf". It takes about 5
seconds for the conversion to complete.

I have checked that the created file is exactly the same as the original
(using cmp). 

Here is some info about what goes wrong (snapshot of the disk while the
command is churning):

ls -l -a:
total 57
drwxr-xr-x    2 www-data www-data      157 Sep 10 12:10 .
drwxrwxrwt    3 root     root           60 Sep 10 12:08 ..
-rw-r--r--    1 www-data www-data    24576 Sep 10 12:08 aaa123.doc
-rw-r--r--    1 www-data www-data       39 Sep 10 12:08
aaa123.pdf.ps.dvi.tex

What is fascinating here is:

(1) the file size of aaa123.doc is wrong! It should be 27136.
(2) the right file of 27136 does occur when commenting out the wvPDF
system command!
(3) the right file size appears after wvWare is killed (this is the Word
View Ware, not VMWare).
(4) wvWare grows very quickly to consuming 500MB of memory and upwards.
(5) I can killall wvWare and then stop and restart zope without having
to restart the computer.
(6) The script returns this message at the console when killall wvWare:
"Could not convert into PS".

While the script is runing I tried manually running wvPDF on the file.
The same churning loop occurred. Once I had killed wvWare I was able to
run the same command fine.

My poor deduction at this stage: the file doesn't appear to close
properly before wvWare is run. There may be a bug in the version of Zope
or Python I am using [Zope 2.3.3 (source release, python 1.5.2,
linux2)]. I'd love to be able to upgrade to see if that solves the
problem but the maintainer of Zope and Python for Debian unstable has
been busy for a long while:

http://lists.debian.org/debian-python/2001/debian-python-200109/msg00003.html

And it looks like a difficult upgrade.

Regards,
Adam