August 2001 - Zope-Dev

RE: [Zope-dev] Problem with starting thread in the initialization of a product ( Linux)
by Lily Li 22 Aug '01

22 Aug '01

Thanks, Steve, it worked! I ran the zope as myself with port 8080. But in the real case, we'll run it as root with port 80. So I'll try to hack z2.py and see if I'm of good luck. Thanks again. Lily Li > -----Original Message----- > From: Steve Alexander [mailto:steve@cat-box.net] > Sent: Wednesday, August 22, 2001 4:20 PM > To: Lily Li > Cc: 'zope-dev(a)zope.org' > Subject: Re: [Zope-dev] Problem with starting thread in the > initialization of a product ( Linux) > > > Lily Li wrote: > > > Hi friends, > > > > I've encountered a serious problem when trying to port my > product from win32 > > system to Linux. > > > > As we need several threads running as long as zope is up > running, we started > > the thread (tried both daemon one and non-daemon one) in > the initialization > > of the product like (in __init__.py): > > > > import threading > > > > def initialize(context): > > ......... > > ......... > > t = threading.Thread() > > t.setDaemon(1) > > t.start() > > > > Then zope will stop responding to any HTTP request. If the > thread is not > > started, the zope will run correctly. Does anyone has the > similar experience > > with it? It seems that the problem is caused by starting thread when > > initializing. I did threading thing before but started by > HTTP request and > > it worked fine. Besides, this code works fine on win32 systems. > > > > If anyone could give me any help as soon as possible, it's highly > > appreciated. > > > Let me guess: > > You've installed Zope as root. > > The problem is that Zope changes uid and gid after initializing the > products. There's a bug/misfeature with Linux in that when a process > changes uid/gid, any existing threads do not change with it. > > If you look up the list archives for problems with Xron, you'll see > reports of similar problems. > > The solutions are to do one of the following: > > * If you don't need Zope to access port 80, or any privilaged > port, run > Zope as a non-root user. > > * Modify Zope to change uid/gid before initializing products. > > * Modify Zope to notify products with a call-back after it > has changed > uid/gid, so that products can do things like launch threads. > > * Modify Linux to fix the problem. > > -- > Steve Alexander > Software Engineer > Cat-Box limited > > > > > >

1 0

Problem with starting thread in the initialization of a product ( Linux)
by Lily Li 22 Aug '01

22 Aug '01

Hi friends, I've encountered a serious problem when trying to port my product from win32 system to Linux. As we need several threads running as long as zope is up running, we started the thread (tried both daemon one and non-daemon one) in the initialization of the product like (in __init__.py): import threading def initialize(context): ......... ......... t = threading.Thread() t.setDaemon(1) t.start() Then zope will stop responding to any HTTP request. If the thread is not started, the zope will run correctly. Does anyone has the similar experience with it? It seems that the problem is caused by starting thread when initializing. I did threading thing before but started by HTTP request and it worked fine. Besides, this code works fine on win32 systems. If anyone could give me any help as soon as possible, it's highly appreciated. Lily Li

2 1

Re: [Zope] select.error: (4, 'Interrupted system call')
by John Ziniti 22 Aug '01

22 Aug '01

I am moving this thread over from the zope list in the hope that someone here may have more insight into the nature of this problem, and perhaps how to go about better diagnosing/fixing the problem. To sum up: Under apparently random circumstances and rather mild amounts of traffic, Zope is crashing and printing the Traceback below to the console. This is Zope-2.4.0, Python-2.1.1 on SunOS 5.8/Sparc. Traceback (most recent call last): File "/u01/zope/Zope-2.4.0-src/z2.py", line 774, in ? asyncore.loop() File "/u01/zope//lib/python2.1/asyncore.py", line 194, in loop poll_fun (timeout, map) File "/u01/zope//lib/python2.1/asyncore.py", line 86, in poll r,w,e = select.select (r,w,e, timeout) select.error: (4, 'Interrupted system call') Any ideas? Thanks in advance, Ziniti On Thu, 16 Aug 2001 14:58:48 +0100 "J. Cone" <jcone(a)g8labs.com> wrote: > Could do. > > The old unix semantics say you deliver a signal to a process. After the > process has split itself into a bunch of threads, it's unclear which one > will get to handle it. I suspect SunOS favours ones that are blocked, > which would make sense if they were blocked in sigsuspend, waiting for a > signal, but that's not your situation :-) > > This conversation may belong on the zope-devel mailing list, where I expect > they have people who understand which signals Zope is supposed to accept, > and how. > > At 09:38 16/08/01 -0400, John Ziniti wrote: > >I just have a hunch this problem has something to do with > >threads, but I don't know why. Does that make any sense? > > > >from $PYTHON_SOURCE/Modules/selectmodule.c: > > > > Py_BEGIN_ALLOW_THREADS > > n = select(max, &ifdset, &ofdset, &efdset, tvp); > > Py_END_ALLOW_THREADS > > > > if (n < 0) { > > PyErr_SetFromErrno(SelectError); > > > >Man, I hate Solaris! I want my Linux box back! > > > > > > > >On Thu, 16 Aug 2001 13:56:45 +0100 > >"J. Cone" <jcone(a)g8labs.com> wrote: > > > >> In my application area, an error like that would mean: > >> - you blocked on a set of file descriptors > >> - either > >> - someone tried to kill you, so you clean up and then exit > >> or > >> - a timer went off so you handle it and then block again > >> > >> Is it possible to handle signals in python and find out who's sending them? > >> > >> Is it running in a terminal > >> (could be ^c'd) > >> or as a daemon > >> (could get SIGTERM on change of run-level) > >> ? > >> > >> Do any other processes on this box incurr stray fingers of G_d? > >> > >> At 08:40 16/08/01 -0400, Chris McDonough wrote: > >> >Geez. I'm not sure, John. This error is being raised by the OS in the > >> >middle of a system call. I don't know enough about Solaris to be able > >> >to give you any direction. Perhaps someone else can chime in? Anybody > >> >else seen this? > >> > > >> >John Ziniti wrote: > >> >> This is SunOS 5.8 running on a Sparc. > >> >> > >> >> On Wed, 15 Aug 2001 17:25:10 -0400 > >> >> "Chris McDonough" <chrism(a)zope.com> wrote: > >> >> > >> >> > >> >>>THis is an odd error... what OS? > >> >>> > >> >>>----- Original Message ----- > >> >>>From: "John Ziniti" <jziniti(a)speakeasy.org> > >> >>>To: <zope(a)zope.org> > >> >>>Sent: Wednesday, August 15, 2001 5:11 PM > >> >>>Subject: [Zope] select.error: (4, 'Interrupted system call') > >> >>> > >> >>> > >> >>> > >> >>>>Hey all, > >> >>>> > >> >>>>I've been getting this all day today since I upgraded > >> >>>>to Python 2.1.1 and Zope-2.4.0. It seems to happen > >> >>>>randomly, but mostly when I am moving around the ZMI, > >> >>>>the more I move around, the more likely it is to occur. > >> >>>> > >> >>>>It also brings down the Zope server, requiring a restart > >> >>>>and is thuis rather annoying. Any ideas on causes, fixes, > >> >>>>hunches? The traceback (printed to console) follows. > >> >>>> > >> >>>>Traceback (most recent call last): > >> >>>> File "/u01/zope/Zope-2.4.0-src/z2.py", line 774, in ? > >> >>>> asyncore.loop() > >> >>>> File "/u01/zope//lib/python2.1/asyncore.py", line 194, in loop > >> >>>> poll_fun (timeout, map) > >> >>>> File "/u01/zope//lib/python2.1/asyncore.py", line 86, in poll > >> >>>> r,w,e = select.select (r,w,e, timeout) > >> >>>>select.error: (4, 'Interrupted system call') > >> >>>> > >> >>>> > >> >>>>Thanks in advance, > >> >>>> > >> >>>>Ziniti > >> >>>> > >> >>>> > >> >>>>-- -- John Ziniti Channing Laboratory Brigham and Women's Hospital 181 Longwood Avenue Brookline, MA 02115 john.ziniti(a)channing.harvard.edu

3 7

PyGreSQL and Zope 2.2.5
by Andre Schubert 22 Aug '01

22 Aug '01

Hi there, I have a problem using PygrSQL and Zope 2.2.5 and Postgres 7.1.2. Sometimes PyGreSQL seems to send a wrong password to posgres, but i don't know why because there are no error in the stupid log of zope. Does anyone know this problem, or does anyone know to trackdown the problem? thanks as

1 0

ZDOM
by Martijn Jacobs 21 Aug '01

21 Aug '01

Hello, Last I was playing around while developping a product when I suddenly found the ZDOM.py, which told me that all ZOPE objects have a DOM implementation of some sort. Now I was wondering how important this implementation is going to be in the future of Zope, In Other Words : Is this DOM implementation going to stay in Zope and will it be expanded in the future? For example, I like the clean syntax of self.getParentNode() instead of getattr(self, 'aq_parent', None); Furtherall is it more easy to learn because the syntax and the meaning of the functions are already familliar by webdevelopers. I'm wondering what other developers think of the ZDOM, I just want your opinion guys :) martijn jacobs eastsite

2 1

Bug w/patch: error in requestprofiler.py meaning it misses a lot of records
by Dyon Balding 21 Aug '01

21 Aug '01

I just submitted this: http://classic.zope.org:8080/Collector/2536/view Description: requestprofiler.py was using the id of the request to index it in the finished dictionary. the id is only guaranteed to be unique for the lifetime of the request, and therefore the same id appears many times in a long log file. in one instance, requestprofiler was only finding 57 hits in a file that actually had close to 4000. this patch changes finished to be a list - it doesn't need to be a dictionary, and solves the problem. Patch: --- /home/dyon/work/ht/zope/Zope-2.4.0/utilities/requestprofiler.py Thu May 17 08:53:43 2001 +++ requestprofiler.py Tue Aug 21 10:10:37 2001 @@ -293,7 +293,7 @@ def analyze(f, top, sortf, start=None, end=None, mode='cumulative'): beginrequests = {} cumulative = {} - finished = {} + finished = [] unfinished = {} while 1: @@ -318,11 +318,10 @@ request.put(code, int(fromepoch), desc) if request.isfinished(): del unfinished[id] - finished[id] = request + finished.append(request) request.active = len(unfinished) - finished.update(unfinished) - requests = finished.values() + requests = finished + unfinished.values() if mode == 'cumulative': for request in requests: -- | Dyon Balding . Software Engineer . HiringTools.Monster.com | dyon(a)hiringtools.com . +1 415 288 3375

1 0

Medusa Status Handler
by Christian Theune 21 Aug '01

21 Aug '01

hi there. i am using the medusa status handler sometimes, and found a bug in the close_zombies part. somebody forgot that he uses socket_map.keys() and tried to .close() on the key, which raised - naturally - an error. status_handler:120: (fixed) for channel_key in asyncore.socket_map.keys(): channel=asyncore.socket_map[channel_key] if channel.__class__ == http_server.http_channel: if channel != request.channel: if (now - channel.creation_time) > channel.zombie_timeout: channel.close() request.done() -- Christian Theune - ct(a)gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])

1 0

New web utility
by Victor Black 21 Aug '01

21 Aug '01

1 0

zDG for 2.4
by Dario Lopez-Kästen 21 Aug '01

21 Aug '01

Hello! I am trying to work thruough the examples of the Zope Development Guide, but I have no sucess in making them work I get this error: >>> Hello.implementedByInstancesOf(HelloComponent) Traceback (most recent call last): File "<interactive input>", line 1, in ? AttributeError: Interface instance has no attribute 'implementedByInstancesOf' Is it possible to use the code in Zope DG with Zope 2-4? How do I set up my puthon (2.1) so that it works with my Zope Install? Any help is appreciated. /dario - -------------------------------------------------------------------- Dario Lopez-Kästen Systems Developer Chalmers Univ. of Technology dario(a)ita.chalmers.se ICQ will yield no hits IT Systems & Services

2 3

Efficient and flexible object references
by Gary & Karyn 21 Aug '01

21 Aug '01

[Originally posted on the main Zope list. Moving it here on recommendation for a deeper discussion.] Hello. I am building a Zope application (described more in full at the end of the message, eliminated here for brevity) that needs to make a large number of object references from other objects. * These references need to be as efficient as possible in terms of size and speed; * moreover, some caching of referenced objects' information, much like Catalog metadata, will be necessary. Hopefully this situation is generic enough that it will be of some interest. I had some ideas on how to do this, and some folks on the Zope list added significantly to my list of both ideas and concerns. The following is a listing of the approaches discussed so far, and their advantages and problems. The Catalog RID idea is dead in the water but tantalizingly close to what I need, so I have included it. Any contributions to further this list in any way would be greatly appreciated. I tried to put attributions in as clearly as possible. Thank you very much to all who have contributed so far. * tree-based Zope URL, or uid ADVANTAGES: The canonical high-level reference approach, apparently. Stable, workable. DISADVANTAGES: Inefficient in storage space No metadata-type information: either wake the object from the ZODB and ask it, or store what you want yourself (very difficult to keep fresh; it is rebuilding the ZCatalog metadata approach from another angle so feels like inventing the wheel) [speed issues in retrieving the object? must already be heavily optimized...] * actual standard object references [From: "Toby Dickenson" <tdickenson(a)devmail.geminidataloggers.co.uk> An alternative that has not been mentioned so far is storing a real object reference.] ADVANTAGES: efficient in storage space DISADVANTAGES: (non-standard Zope approach) No metadata; must wake the object to get the information From: "Toby Dickenson" <tdickenson(a)devmail.geminidataloggers.co.uk> > This may well be easier if you can live without managing your > relationships as if they were folders, and without using Zopes > security mechanisms to control accees to the referred-to objects. Therefore, referenced objects would either not be accessible and manageable via Zope (losing much of Zope's advantage as an object publisher), or they would be in a scary netherworld--in a Zope management tree but also directly referenced outside of it--in this case a hack that would probably cause significant problems. I think Toby meant the first scenario. My app would have to use the second scenario (the objects should be published), which is why I had not pursued it. * Catalog (ZCatalog) rids (currently DEAD IN THE WATER but tantalizingly close to what I want) ADVANTAGES: Efficient use of space Can return metadata without waking actual object (a design goal of the ZCatalog, I believe) Metadata is updated whenever the catalog is updated (hopefully in approximate real time)--no new mechanism needed to keep metadata fresh (we're using a wheel that has already been invented) All of the needed methods except hasuid (i.e. getRID) are part of what I assume is the interface: getobject, getMetadataForRID, getIndexDataForRID, getpath DISADVANTAGES: From: "Dieter Maurer" <dieter(a)handshake.de> > "rid"s are not persistently associated with objects. > If someone calls "manage_catalogReindex", then all your rids change. [that's the killer] Also, a hack, unless it were blessed by ZC at some point, because it relies on inner workings of the Catalog (i.e., the ZCatalog has no method to return an object's rid, and the catalog itself only has hasuid, which as named does not imply reliability as a way of getting RID) * ZODB oid [From: "Casey Duncan" <cduncan(a)kaivo.com> > Another option to explore might be to store the oid] ADVANTAGES: efficient use of space DISADVANTAGES: From: "Toby Dickenson" <tdickenson(a)devmail.geminidataloggers.co.uk> > OIDs are only unique within a single storage. > > * If some objects are exported and reimported, their OIDs > will change. > > * You will get duplicate OIDs in the same Zope if you are > using a mounted storage. From: "Dieter Maurer" <dieter(a)handshake.de> > * they are a very low level feature, difficult to > access from most Zope parts > > * they may not be unique > Think of "mountable storages". > Then each storage will have its own OID's, interpreted > in its own local context. ---------- As the list above stands now, I will either use a standard tree-based URL uid and try to build my own optimized caching mechanism (ouch) or go down the treacherous and very dangerous path (for the future) of attempting to make the ZCatalog do what I want no matter what. I suppose my first step there would be to see if I can find a way to allow reindexing of a catalog without changing RIDs... I can feel the frowns from here... Thanks for your ideas. For those of you still here, a few paragraphs describing my project more fully follow. Only read them if you feel they will help your brainstorming. :-) Thanks Gary ---------------------------------------- CASUAL PROJECT DESCRIPTION from an earlier post While I keep an eye to contributing back to the community by making my solutions as flexible as possible, I'm putting a super-bibliography for musicians, especially vocalists, into Zope. It stores objects describing compositions, books, texts, recordings, publications, people, topics, and other items. On a simple level, I need the kind of referencing I describe for connecting people objects as creators to other objects; for connecting any object to another (particularly topics) in a "describes" relationship; for connecting same-class objects in a parent-child relationship; and other similar tasks. (Obviously, I'm coming from a bit of a RDBM background on this but I'm enjoying the better modeling possible with the ZODB, among other things.) When a composition object displays, for instance, it needs to both know the name and address of all of it's creators, ideally without waking up the creators yet. Similarly, a person needs to know back links--what objects claim me as a creator? Rather than caching a page or an object, I have decided it will be best to cache the relationships and metadata somehow. ----------------- More details for the super-interested ------------------- The modelling for compositions is particularly complex, at least to me, since I include instruments needed, if any, and voices needed, if any; the voices themselves have high and low range extremes I am keeping track of, and even multiple options for those. If they are published, each song might be transposed by a given number of half steps (producing a new set of the high and low extremes for the composition). If the composition's parent is published and transposed, that means that will produce yet another set of high and low extremes. Displaying and searching by range extremes thus becomes quite complex, and a high, high candidate for caching. Even so, expecting my code to keep the cached information fresh when the relationships are so far-flung makes me nervous: I think I'll only be able to cache so far down the chain, and rely on live checks (or at least secondary cached metadata checks) for the rest. I'm figuring I'm going to need a new pluggable index, based on the work in PathIndex, for the complicated range searches and some other needs; an interlinking class that manages inter-object back and forward links behind the scenes for caching and getting the cached metadata I described; and some simple subclasses that will represent each of the data types. I have plans from there as well, but those are first steps.

8 19