Zope lockups using an External Method
Hi all, I've been learning Zope for a while but I'm now so completely stuck that I thought it would be a good time to join the mailing list :-) My platform is Debian GNU/Linux unstable x86 running the 2.4.9 kernel. w/Zope 2.3.3 (source release, python 1.5.2, linux2) Running a particular External Method (clicking on the DTML Document and then clicking the View tab) leads to Zope locking up and the computer system going very sluggish. A reboot fixes everything. I can rewrite the script so it runs separately from the command line. However once it is called as an external method it misbehaves. The specifics: I execute this DTML Document: <dtml-var "Doc2PDF(Karl_Le_Quesne)"> (Karl_Le_Quesne is the id of the Word Document in the Zope Database. For some reason I need to remove the .doc extension. It seems that objects can't have a full stop in them?) Which calls this External Method: def Doc2PDF(self, inputdoc): import os import tempfile import sys import random import StringIO #For some reason this stopped working below #And now returns "None" #temp_path=tempfile.tempdir temp_path='/var/tmp' random_dir=str(random.randrange(100000000,999999999)) full_dir=temp_path+'/'+random_dir os.chdir(temp_path) os.mkdir(random_dir) os.chdir(full_dir) #Put the file onto the hard disk thefile=open('aaa123','w') thefile.write(inputdoc.data) thefile.close # Run wvPDF on the document os.system('wvPDF aaa123 aaa123.pdf') return aaa123 is a word document. Can anyone see what has gone wrong? Note that the External Method properties are id = Module Name = Function Name = Doc2PDF 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. Many thanks, Adam
Adam Warner writes:
.... Zopes locks in External Method .... I execute this DTML Document:
<dtml-var "Doc2PDF(Karl_Le_Quesne)">
(Karl_Le_Quesne is the id of the Word Document in the Zope Database. For some reason I need to remove the .doc extension. It seems that objects can't have a full stop in them?) 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')".
.... 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.
# 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".
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?
I would use "ps" to analyse what process plays havoc. After I had identified the process, I might use "gdb" or "strace" to find out what it does.... Dieter
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.htm... And it looks like a difficult upgrade. Regards, Adam
On Mon, 2001-09-10 at 13:23, Adam Warner wrote:
On Mon, 2001-09-10 at 05:48, Dieter Maurer wrote:
(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).
Some more evidence: If I do an 'ls -l -a' on the directory within the script itself (after the file has been closed) I find the file size is wrong. But it is correct straight after the script completes. So wvPDF is obviously getting stuck on a truncated Word file (truncated by 2560 bytes). But there doesn't appear to be anything wrong with these commands: thefile=open('aaa123.doc','w') thefile.write(str(inputdoc.data)) thefile.close I'm using ReiserFS. Regards, Adam
On Mon, 2001-09-10 at 14:05, Adam Warner wrote:
thefile=open('aaa123.doc','w') thefile.write(str(inputdoc.data)) thefile.close
The answer is simple. Being a Python newbie at first I didn't notice the problem. The last line should read: thefile.close() Then the file actually closes and everything works :-) Regards, Adam
participants (2)
-
Adam Warner -
Dieter Maurer