Re: [Zope] ZEO troubles on RedHat EL4 Linux
[Dieter Maurer] > There is one essential thing you stress over and over again -- but > which I am not sure: > > You say, the exception in "tearDown" means that > the test completed successfully -- without any error. Oh no, that's not what I'm saying. As you say next, > However, I am convinced that "tearDown" is called, too, > when the test fails. That's right, it does. What I said is that _if_ the only listing of errors/failures we've seen here was in fact an exhaustive list of all the errors/failures that were seen in that run, _then_ we can deduce that the tests passed. That's simply because if a test body failed, that would have produced an _additional_ error/failure report. But every one of the error/failure output blocks in the message showing them was the same waitpid() complaint, reached from tearDown(). Assuming this was an exhaustive listing, there were no error/failure reports of any kind stemming from test setup or test body code, only from test teardown code. So it's not that I saw an error in tearDown() that causes me to believe "the tests passed", it's that we haven't seen any errors/failures _other_ than tearDown() errors. Willi was later kind enough to include what looked like a screen scrape of an entire test run, and I think we can be sure of that there: """ Running one single test: bender:~/Zope-2.7.7-final$ python2.3 test.py testConnection checkNoVerificationOnServerRestart\$ Running unit tests from /home/wlang/Zope-2.7.7-final/lib/python == ERROR: checkNoVerificationOnServerRestart (ZEO.tests.testConnection.FileStorageReconnectionTests) -- Traceback (most recent call last): File "/home/wlang/Zope-2.7.7-final/lib/python/ZEO/tests/ConnectionTests.py", line 121, in tearDown os.waitpid(pid, 0) OSError: [Errno 10] No child processes -- Ran 1 test in 0.689s FAILED (errors=1) """ If the setup code or body of checkNoVerificationOnServerRestart had something to complain about too, I would expect to see an additional blob of ERROR or FAILURE output. The ConnectionTests.py code that starts a ZEO server process doesn't swallow exceptions, and simply cannot add the pid returned from spawnve() to its list of tids to wait for later unless ZEO/tests/forker.py's start_zeo_server() returns normally. > I did not point this out earlier, because you are probably right. > > If the test itself had failed, we should probably have seen > a previous exception and a "pid" cannot be registered for > later clean up before it was created. As above, yes. > Looks as if there were something that eats the dead child before > the "waitpid" could take care of it. Yup. > I know that a SIGCHLD/SIG_IGN can do that > or a "waitpid(pid)" with "pid <= 0". > > If for some reason, a value "<= 0" happened to arrive in the > list of processes to be cleaned up, then this could explain > the strange non-deterministic behaviour. Perhaps they can add some print statements or asserts then, to test that possibility. From the Python docs: If pid is 0, the request is for the status of any child in the process group of the current process. If pid is -1, the request pertains to any child of the current process. If pid is less than -1, status is requested for any process in the process group -pid (the absolute value of pid). If the OS happens to return a pid "with the sign bit set", I'm not sure whether the Python implementation of all this stuff would manage to do "the right thing". Python's waitpid() wrapper definitely treats the pid as a native signed C int, not as being of type pid_t. OTOH, pid_t isn't part of standard C, it's a Unix thing, and I believe pid_t _is_ C int in glibc. If so, then a pid "with the sign bit set" is simply impossible to use in a call to waitpid(), so it would be an OS bug if it ever returned a pid with the sign bit set. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] OOP and Zope.
--On 19. August 2005 12:16:55 -0600 Fernando Lujan <[EMAIL PROTECTED]> wrote: Hi, I try to find information about programming in Zope with the OO paradigm. I didn't find many documentation... For instance, how can I define classes and instances once I just work with dtml-methods and dtml-documents? And btw. if you are familiar with Python you should perhaps look first at Zope 3 which is more pythonic for doing OO-like web programming. -aj pgpuYevD1zzqy.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] OOP and Zope.
--On 19. August 2005 12:16:55 -0600 Fernando Lujan <[EMAIL PROTECTED]> wrote: Hi, I try to find information about programming in Zope with the OO paradigm. I didn't find many documentation... For instance, how can I define classes and instances once I just work with dtml-methods and dtml-documents? dtml-methods and dtml-documents have nothing to do with OO programming. Their purpose is to provide a markup language to write views on objects or whatever. Btw. forget DTML and learn ZPT. When you talk about OO programming: look at the Zope Developers Guide and learn how to write first class Zope objects. But before you should go through the Zope Book and learn about the basic of Zope before starting Zope Product development. -aj pgpxBAkU6Z1lZ.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Workflow question
Hi Dieter. This is an excellent idea! I was looking at this to restrict the content that could be put into the folder as well. This fits really well with this too. First step is to make new type - will do this today but might need to ask a question or two when I get to bobo traverse portion. When you say another auxillary object, what kind of object is this so I understand a bit better? In anycase, I'll get going on making the type so I can look at this part with something that is ready to go. Regards David I would approach this task by means of a specialized folder (say some "UploadFolder"). In its "__bobo_traverse__" method, it would not return a "webdav.NullResource" but instead another auxiliary object. Its "PUT" method can do whatever you want it to do, e.g. not creating an object but telling FTP/WebDAV about a successful operation. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] OOP and Zope.
Hi, I try to find information about programming in Zope with the OO paradigm. I didn't find many documentation... For instance, how can I define classes and instances once I just work with dtml-methods and dtml-documents? Thanks. Fernando Lujan ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ZEO troubles on RedHat EL4 Linux
Hi Tim, Tim Peters wrote at 2005-8-19 11:15 -0400: > ... >"The tests are dodgy" sounds >appealing until you think about what they do related to the point of >failure: spawn a process, and wait for it to exit later, passing >waitpid() the pid returned by spawnve(). There just isn't anything >complicated (at the Python level) going on there. There is one essential thing you stress over and over again -- but which I am not sure: You say, the exception in "tearDown" means that the test completed successfully -- without any error. However, I am convinced that "tearDown" is called, too, when the test fails. I did not point this out earlier, because you are probably right. If the test itself had failed, we should probably have seen a previous exception and a "pid" cannot be registered for later clean up before it was created. Looks as if there were something that eats the dead child before the "waitpid" could take care of it. I know that a SIGCHLD/SIG_IGN can do that or a "waitpid(pid)" with "pid <= 0". If for some reason, a value "<= 0" happened to arrive in the list of processes to be cleaned up, then this could explain the strange non-deterministic behaviour. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ZEO troubles on RedHat EL4 Linux
Tim Peters wrote at 2005-8-18 17:16 -0400: > ... >I'm not sure Dieter's info is current either. The SIGCHLD handler in >current Zope 2.7.7's zopectl.py explicitly catches and ignores the >specific exception you reported: Good! Something like that I did for our Zope 2.7.2. > ... >But looks like Dieter added that code to begin with, so hard to >believe he forgot about it ;-) Sometimes, changes by me happen to land in in the core distribution either via the Zope collector or because Andreas put them in there. In both case, I do not necessarily know about that. I have not (yet) modified directly core Zope code. Maybe, in the near future... -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Workflow question
David Pratt wrote at 2005-8-18 20:57 -0300: > ... >All for exception of one thing - I want to >delete the object as part of the workflow since it is no longer needed. > ... >I use manage_delObjects like so: > > # Delete original object from the upload folder > upload_dir.manage_delObjects([id,]) > >method it raises following traceback: > >Traceback (innermost last): > > * Module ZPublisher.Publish, line 113, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 40, in call_object > * Module webdav.NullResource, line 138, in PUT > * Module Products.CMFCore.PortalFolder, line 393, in PUT_factory > * Module OFS.ObjectManager, line 261, in _getOb > >AttributeError: A1032.JPG > >I guess my question is how can you delete an object that really is not >there yet, correct Correct. > ... >Because I already have already obtained what I need from the FTP'd >file, is there a way to give the FTP process something after the PIL >process to have it think it has completed its job and send a 226 >Transfer complete. This way I think workflow should be happy, FTP will >be happy because it gets a successful transfer, and I will be happy >because there is no file in the upload directory to worry about >deleting. Even it is a very different kind of situation, perhaps it >can still work. I would approach this task by means of a specialized folder (say some "UploadFolder"). In its "__bobo_traverse__" method, it would not return a "webdav.NullResource" but instead another auxiliary object. Its "PUT" method can do whatever you want it to do, e.g. not creating an object but telling FTP/WebDAV about a successful operation. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Cancelling long processes in Zope
Ausum Studio wrote at 2005-8-19 01:31 -0500: >How do you stop a long process just triggered, i.e., by accident? If the process is an external process (rather than a thread), you sent it a signal (e.g. a SIGTERM). This may not work in Python 2.3.x for most signal, as these Python versions block signals in the non main thread and this is passed down to processes created by these threads. A process can however reactivate some (or all) signals. Furthermore, the process can still be killed with signal SIGKILL. The bug is fixed in Python 2.4. If the process is rather a thread, it is very difficult to stop it. If the thread is inside a C extension, you cannot abort it without the risk to lose resources or get into inconsistencies (there is no "try: ... finally: ..." in "C"). Python has a C level API function that allows you to deliver an exception to a thread. Once the thread reaches Python again, it will see the exception and process it in the normal way. This might help you in some maybe most cases -- but probably not always... -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Uninstalling a product in a ZopeTestCase
Marco Bizzarri wrote at 2005-8-19 10:49 +0200: You may look how the "refresh Product" function uninstalls a product. You find the code in "App.RefreshFuncs.performRefresh". -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
FIXED: Re: [Zope] URL0 returns index_html not index.html
John Eikenberry wrote:
Mark Barratt wrote:
I can vaguely see why this is happening. My question: is there a
straightforward way of making the links (and error reports) return the
actual page address?
By actual page address you want the URL with index.html instead of
index_html? Given your current setup as described, redirecting would work.
Well, no, because some of the objects I want to append /source.html to
are not called index.html (but that *is* how we did it for another site
and it works as you say).
A text substitution covers both cases:
tal:attributes="href
python:context.REQUEST['URL0'].replace('index_html','index.html')+'/source.html'"
If you were working with zope projects there are other tricks you could
pull, but it doesn't sound like you are doing this.
I don't understand this: is a 'zope project' different from my project
using zope?
Thanks to you and Dieter for the help
--
Mark Barratt
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ZEO troubles on RedHat EL4 Linux
[Willi Langenberger] >> Interesstingly, if i run the test with strace, i never see the test >> fail (i tried at least 30 times): [Jens Vagelpohl] > This sounds like something Tim had mentioned at one point, where > tests can fail on a machine that is "too fast"? Dieter said that. I believe him, but it doesn't match my experience. Then again, I spend most of my time on Windows boxes, where process creation is so much slower (than on Linux) that Dieter can't even imagine that many orders of magnitude . Andres Krasa reported that his tests were running on an Intel Xeon 3 GHz Dual-CPU box. Does nobody else here run on a Linux box that fast? I normally run tests on a 3.4 GHz hyperthreaded box, but it _is_ running WinXP instead, and the spawnve and waitpid implementations on Windows have nothing in common with their Linux implementations (e.g., most Unix signals, including SIGCHLD, don't exist on Windows -- the OSes have very different ways of managing processes). > Both with strace and the debugger you "slowed the test down" a bit, and > they pass. Maybe that's a clue, basically pointing to the fact that the tests > are > dodgy rather than the software? Trying to come up with a small, self-contained test case remains (IMO) the best way to make progress here. "The tests are dodgy" sounds appealing until you think about what they do related to the point of failure: spawn a process, and wait for it to exit later, passing waitpid() the pid returned by spawnve(). There just isn't anything complicated (at the Python level) going on there. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ZEO troubles on RedHat EL4 Linux
[Willi Langenberger] > Ok, here some data points... > > bender:~/Zope-2.7.7-final$ cat /proc/version > Linux version 2.6.9-11.ELsmp ([EMAIL PROTECTED]) (gcc version 3.4.3 20050227 > (Red Hat 3.4.3-22)) #1 SMP Fri May 20 18:26:27 EDT 2005 > > bender:~/Zope-2.7.7-final$ python2.3 > Python 2.3.5 (#1, Apr 19 2005, 14:53:39) > [GCC 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)] on linux2 > ... > > Running one single test: > > bender:~/Zope-2.7.7-final$ python2.3 test.py testConnection > checkNoVerificationOnServerRestart\$ > Running unit tests from /home/wlang/Zope-2.7.7-final/lib/python > == > ERROR: checkNoVerificationOnServerRestart > (ZEO.tests.testConnection.FileStorageReconnectionTests) > -- > Traceback (most recent call last): >File > "/home/wlang/Zope-2.7.7-final/lib/python/ZEO/tests/ConnectionTests.py", line > 121, in tearDown > os.waitpid(pid, 0) > OSError: [Errno 10] No child processes > > -- > Ran 1 test in 0.689s > > FAILED (errors=1) > > After some retries, the same test passes: > > bender:~/Zope-2.7.7-final$ python2.3 test.py testConnection > checkNoVerificationOnServerRestart\$ > Running unit tests from /home/wlang/Zope-2.7.7-final/lib/python > -- > Ran 1 test in 0.691s > > OK > > Interesstingly, if i run the test with strace, i never see the test > fail (i tried at least 30 times): > > bender:~/Zope-2.7.7-final$ strace -e trace=signal -o /var/tmp/zeotest.trc > python2.3 test.py testConnection checkNoVerificationOnServerRestart\$ > Running unit tests from /home/wlang/Zope-2.7.7-final/lib/python > -- > Ran 1 test in 0.710s > > OK > > (Obviously a Heisenberg effect -- the observation influences the > behaviour ;-) Not unusual, alas. What's more peculiar is that nobody else on this list reports the same problem. Then again, we have no way to know whether anyone other than Jens and I _tried_ to ;-) > If anyone is interessted in the trace file -- it can be found at: > > http://slime.wu-wien.ac.at/misc/zeotest.trc > > (However, it would be way more interessting to see the syscalls while > the test is failing...) Someone more up-to-date than I on the vagaries of Linux signals and strace might be able to deduce something from that about how SIGCHLD is treated by this OS. AFAICT, the SIGCHLD handler was set to SIG_DFL shortly after Python started, and wasn't fiddled with again. I don't know the exact intended meaning of every character in the: --- SIGCHLD (Child exited) @ 0 (0) --- lines near the end of the trace either. > Also, i debugged the whole test with the python debugger. Unfortunatly > (as with strace), i was not able to reproduce the failing of the test > in the debugger. [Tim] >> the ZEO tests spawn processes directly via Python's >> os.spawnve(), and later waits for them to end, via the waitpid() code >> shown earlier. It doesn't muck around with signals, forks, or >> anything else that should be platform-dependent (the same ZEO-test >> process code is used on both Linux and Windows, BTW -- for this >> reason, it can't rely on any fancy signal or process gimmicks; >> spawnve+watipid is the entire story here). > Yes, its as simple as that: zeo ist started, zeo is stopped, and when > the parent calls waitpid, we get the "No child processes" error most of > the time :-( > > Any ideas what we can try to narrow this down? Whittle it down. If I had a box on which I saw the problem, the next thing I'd try is writing a tiny Python program that did nothing other than spawn a simple process and then wait for it finish. So far, there's no particular reason to believe that the mountain of Zope/ZODB/ZEO code really has anything to do with this, right? The outcome of trying to remove all that from the equation would suggest a next step. ... > Sure -- we could just make this change: > > bender:.../ZEO/tests$ diff ConnectionTests.py.ori ConnectionTests.py > 121c121,124 > < os.waitpid(pid, 0) > --- > > try: > > os.waitpid(pid, 0) > > except OSError: > > pass > > then all tests will pass. That should be verified (by actually trying it). For one thing, I count 8 instances of "os.waitpid(pid, 0)" in the Zope-2_7-branch branch, and it would be surprising if the other 7 always worked on your box, right? ;-) > But then we will not know why the zeo zombie vanishes before > the waitpid can reap the exit code ;-) Right, it would be papering over a symptom, leaving the cause unknown. If you find that expedient in your installation, that's fine, it's a key advantage of open source that you can worm around problems on your o
[Zope] Workflow & automatic trigger from FTP (PUT) (was Workflow Problem)
An automatic trigger in workflow appears possible from FTP'd content but to soon to be involved in zope heirarchy. You can get hold of the state_change object from the workflow itself but methods that would normally be available such as its data attribute or manage_ xxxObjects type methods are unavailable since the object does not enter the heirarchy until the FTP transaction has completed. A FTP 426 Error results with any attempt to use any of these methods. But it is still possible to use the automatic transition and obtain the body from the FTP request and do something with the file data. The automatic transition I am writing involves removing the object after it has been transferred to the site (since it is only used to make a few objects, the data is large and not important to store it afterwards). So am able to use the data from the object being FTP'd in the automatic transition's script (which is good) but am looking for a solution to provide the FTP client with an 226 Transfer complete message to complete its transaction after doing what I want with the data (without the file landing in the folder). manage_delObjects cannot be used in the script since the object is really not in the folder itself until after FTP transaction completes. The problem with letting the FTP transaction complete is that I cannot think of a way to have a fully automatic process - since automation in workflow with any number of states would still be sequential and before FTP transaction is complete. So I would likely have to cron a process to clean up the folder (which is undesirable). Regards, David ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] setting mime type for a python script
--On 19. August 2005 15:49:31 +0200 santiago <[EMAIL PROTECTED]> wrote:
hello
I'm looking for a way to set the mime type served by zope for a python
script.
I found something for products (looks like :
self.self.setFormat(self.content_type) )
but I just can't get that working in my script, because self is not
available in scripts
any idea of how I could get my script being served as a text/css ?
FAQ: context.REQUEST.RESPONSE:setHeader('content-type', 'text/css')
-aj
pgpmGPIz6GEeV.pgp
Description: PGP signature
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] setting mime type for a python script
hello I'm looking for a way to set the mime type served by zope for a python script. I found something for products (looks like : self.self.setFormat(self.content_type) ) but I just can't get that working in my script, because self is not available in scripts any idea of how I could get my script being served as a text/css ? thanks ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Uninstalling a product in a ZopeTestCase
Hi all.
I'm trying to write a ZopeTestCase where I can check if the import of a
missing module is catch or no. I would therefore test something like this:
def testImportIsCaught(self):
import sys
oo_path = filter(lambda x: 'program' in x, sys.path)
sys.path.remove(oo_path[0])
ZopeTestCase.installProduct('PAFlow')
What I'm doing here is to remove the path where the openoffice support
is in the system, and then I try to install the product. If the
exception import is caught, this should not raise an exception.
The problem is that if I run all the tests, I will end with my product
already installed, and, therefore, the test won't be run correctly.
Do anyone has any suggestion?
Regards
Marco
begin:vcard
fn:Marco Bizzarri
n:Bizzarri;Marco
org:Icube S.r.l.
adr:;;via Ridolfi 15;Pisa;PI;56124;Italy
email;internet:[EMAIL PROTECTED]
title:Amministratore Delegato
tel;work:+39-050-970-207
tel;fax:+39-050-3136-588
tel;cell:+39-348-640-4861
x-mozilla-html:FALSE
url:http://notenotturne.blogspot.com/
version:2.1
end:vcard
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] ZEO troubles on RedHat EL4 Linux
On 19 Aug 2005, at 02:22, Willi Langenberger wrote: According to Interesstingly, if i run the test with strace, i never see the test fail (i tried at least 30 times): This sounds like something Tim had mentioned at one point, where tests can fail on a machine that is "too fast"? Both with strace and the debugger you "slowed the test down" a bit, and they pass. Maybe that's a clue, basically pointing to the fact that the tests are dodgy rather than the software? jens ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
