April 2000 - Zope-Dev

RE: [Zope-dev] Extensions directory
by Chris McDonough 14 Apr '00

14 Apr '00

In CVS at least (and maybe in stable revs?), Jim F. provided the capability to store external methods within a Product directory's 'Extensions' directory, referenced by an external method in a module with the name "ProductName.ModuleName". So if you've got an extension directory that has lots and lots of external methods from lots and lots of Products, you can break them up and store them in their respective product Extension dirs. > -----Original Message----- > From: jpenny(a)universal-fasteners.com > [mailto:jpenny@universal-fasteners.com] > Sent: Friday, April 14, 2000 3:06 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] Extensions directory > > > Background: > I find that I am writing quite a bit of External python code that is > quite task specific; probably far too task specific to try to > package. For example, I have an (internal only) page that shows > part consumption on a per machine basis. There are hundreds > of machines, > and thousands of parts, so the graphs must be produced dynamically. > > This is pretty easy to do. (I use ploticus, a great open source > tool, http://www.sgpr.org/.) But I can see, down the road, being > requested to produce many different sorts of graphs. And since > the data stream will have differing types and number of arguments, > it is not clear that it would be easy to write a Product, even if > I had the inclination. > > But, I hate to have many scripts in a single flat directory. > This can be > both a mess to maintain and can slow things down on some file-systems. > > So, is there any strong reasons that the Extensions directory needs > to be flat (i.e. not have subdirectories)? > > Jim > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) >

1 0

Extensions directory
by jpenny＠universal-fasteners.com 14 Apr '00

14 Apr '00

Background: I find that I am writing quite a bit of External python code that is quite task specific; probably far too task specific to try to package. For example, I have an (internal only) page that shows part consumption on a per machine basis. There are hundreds of machines, and thousands of parts, so the graphs must be produced dynamically. This is pretty easy to do. (I use ploticus, a great open source tool, http://www.sgpr.org/.) But I can see, down the road, being requested to produce many different sorts of graphs. And since the data stream will have differing types and number of arguments, it is not clear that it would be easy to write a Product, even if I had the inclination. But, I hate to have many scripts in a single flat directory. This can be both a mess to maintain and can slow things down on some file-systems. So, is there any strong reasons that the Extensions directory needs to be flat (i.e. not have subdirectories)? Jim

1 0

RE: [Zope] Re: Zope hanging (poss. threads-related)
by Marcus Collins 14 Apr '00

14 Apr '00

> -----Original Message----- > From: Amos Latteier [mailto:Amos@digicool.com] > Sent: 13 April 2000 20:53 > To: 'Tres Seaver'; Marcus Collins > Cc: zope-dev(a)zope.org > Subject: RE: [Zope] Re: Zope hanging (poss. threads-related) <snip> > The ZServer zombie stuff is to get rid of zombie client > connections, not zombie publishing threads. These are quite > different beasts. Thanks for the clarification. I'm still on my way to understanding how it all fits together... > > > Everything before the call to handle() is 100%. Sometimes, > > > however, we don't get from handle() to the next stage. This is > > > on Zope 2.1.6, which I've been running with up to 100 threads, > > > although I unfortunately can't excercise that many! > In general there is little reason to have so many publishing > threads. > You almost never need that many unless you have a bunch of > requests that can take a *long* time. > > If, on the other hand, you are trying to provoke some kind of > thread contention issue I advise you to publish resources that take > a long time to return. That way you can easily pile up as many > publishing theads as you want to. Normally, I'd estimate that 20 threads would be sufficient for our site, and that's what we want to run. We have some search queries that may take a number of seconds to complete. However, in this instance, I was deliberately attempting to hang threads. The pages of our site on which I've noted hanging occurring take much less than a second to publish; no hanging problems have been noted on pages which take significantly longer (say, 10 or 20 seconds in the extreme) to publish, although possibly that's a statistical probability. > > > I've added this logging to the Zope 2.1.3 serving the live > > > site, and will report my findings as soon as something untoward > > > occurs. Maybe others who are experiencing hanging would also be > > > able to do some extra logging and report the results [now, > > > there, I see Wiki would be really useful!]. I've described at http://www.zope.org/Members/tseaver/Projects/HighlyAvailableZope/DiagnosingH angProblems/DebugLogger how I've set up DebugLogger to give a greater granularity to the logging of requests. Perhaps, if other users also discover threads hanging, they could post their results there? Since extending the logging, I have found that the hanging occurs less frequently; when I reduced the logging again, the hanging recurred -- specifically, when I reduced the logging in send_response() in PCGIServer.py. The logs then indicated that the request failed sometime between found_terminator() ending and the return from HTTPRequest() in send_response(). Note that this is _different_ to my previous posting, where I indicated that the request failed before handle() returned. Both of the reports are true, so it seems we haven't managed to nail it down quite as well as I thought... The hangings that I've now recorded in testing occurred with Zope 2.1.6 when NUMBER_OF_THREADS was set at 10. It's also hung with 4 and with 20 threads. To be fair, though, since adding additional logging, I've really had to pound it (20-30 simultaneous users, abnormally heavy usage) to get it to hang. The hangings on the live site (Zope 2.1.3) have occurred under light load (one or two users), first with 20 threads, and now with 4. > In my experience when a Zope publishing thread hangs its > almost always a problem with the published resource. Maybe there's > something that puts Zope in a loop that never exits, or maybe > there's some DA weirdness that hangs the thead. > My advice is to try and identify which requests hang using > debug logging and examine the resources that those requests use. The specific resources on which this hanging has occurred are: - /manage_*, but not yet when using manage_main alone (again, perhaps a statistical probability) - a frameset page on our site, which uses: * ZSQL methods calling a MySQL database (MySQL 3.22.27/32; ZMySQLDA 1.1.3 patched with MySQLdb 0.1.0; db connection pool_size equal to NUMBER_OF_THREADS) * GUF 1.2.2 (using the database) * SiteAccess 1.0.1. A single thread at a time hangs. Recently, however, when /manage was accessed shortly after a thread hung, ZServer became completely unresponsive to http or pcgi (didn't check ftp...). I'll be putting this and further details up at http://www.zope.org/Members/tseaver/Projects/HighlyAvailableZope/MarcusColli ns as soon as I get a chance. Unfortunately, that's not likely to be before Monday. Thanks All. -- Marcus

1 0

RE: [Zope] Re: Zope hanging (poss. threads-related)
by Marcus Collins 14 Apr '00

14 Apr '00

[following suit and moving this over to zope-dev.org] > -----Original Message----- > From: Tres Seaver [mailto:tseaver@palladion.com] > Sent: 13 April 2000 19:55 > To: Marcus Collins; zope-dev(a)zope.org > Subject: Re: [Zope] Re: Zope hanging (poss. threads-related) > Hmm, _I_ was the one making that argument. I guess I wasn't > really urging everyone to quit posting to the list -- rather, I > hoped that the community could "harvest" the information from the > list and massage it into a useful format for problem solving (e.g., > to make it possible to notice connections bewteen pieces > of information which appear on the list at fairly disparate times). > Most of the pages I put up there to start with wree attempts to > categorize types of problems, and also potential sources of them. OK, I'm afraid I misunderstood you at first. I've seen the fault of my ways, repented, and quite agree with you and with Michel, that the Wiki is in fact quite suited to this. I'll be putting up bits and pieces there as soon as I can get a chance (and, I confess, figure out Wiki :-). > Perhaps is was a caching issue? I clicked the link, saw that > I was not logged in, logged in, returned to the page, and had to > force a reload to see the "Edit this page" links. This was indeed the problem; certainly operator failure not to realise it... Thanks. Now back to documenting the problem! -- Marcus

2 1

Zope and PIL problems?
by Townsend Duong 14 Apr '00

14 Apr '00

Is anybody else having problems getting Zope and PIL to work together? I'm trying to get Zope to use PIL to generate some images and load them into the Zope database. PIL claims it can't find the font file (or the glyph file). After hunting this bug for a while, I discovered that it has the file just fine, but it can't seem to open the glyph file because the line 'return factory(fp, filename)' in Image.open leads to an IOError. I tried ignoring the font problem temporarily, but then I got errors with the Image.save. It leads to ImageFile._save, which brings up an attribute error. Both open and save work fine from the command line 'interactive mode', and I've been able to get PIL to do these sorts of operations outside of Zope. I even loaded the font from the command line while Zope kept complaining. In case it helps, I'm using Zope 2.1.6, Python 1.5.2, PIL 1.0 final, and PILGraph 0.1a7. TD *--------------------------------------* | Townsend Duong | | Stanford University Computer Science | | beehive elektronische medien GmbH | | Handy: 0178 / 33 77 77 6 | | Email: townsend(a)beehive.de | *--------------------------------------*

1 0

Creating ExtensionClass instances in C
by Andrew M. Kuchling 14 Apr '00

14 Apr '00

Here's a simple question about the ExtensionClass API: if I write an ExtensionClass, how do I create an instance of it from C code? There's no obvious API function that does this... --amk

3 2

RE: [Zope] Re: Zope hanging (poss. threads-related)
by Marcus Collins 13 Apr '00

13 Apr '00

> -----Original Message----- > From: Tres Seaver [mailto:tseaver@palladion.com] > Sent: 13 April 2000 04:11 > To: zope-dev(a)zope.org > Cc: Monty Taylor; Michel Pelletier; Marcus Collins; Chris McDonough; > Amos Latteier; Jim Fulton; Brian Lloyd > Subject: Re:[Zope] Re: Zope hanging (poss. threads-related) Firstly, it's great to see the involvement of all these brains! Thanks to all of you! Secondly, sorry for the cross-posting... please don't hang me ;-) > I would *really* like for us to capture the information > flowing through the list in some less ephemeral form, so I have set up > a Wiki for discussing this and other availability/stability/ > reliability issues at: > http://www.zope.org/Members/tseaver/Projects/HighlyAvailableZope/ Tres, I also agree that this should not get lost amongst all the regular traffic. This list is busy enough as it is. However, perhaps other folk (Jerome Alet, others?) are just now beginning to say "me too", and so the rest of the list does need a chance to be involved. Not everyone is a member at zope.org either, and perhaps not everyone understands how Wiki works. It can also prove difficult, unless someone is moderating the posts, to not get tangled, whereas a threading mail client... this is basically just the same argument as was levelled about a week ago at the suggestion of using Wiki for bug tracking. Wiki is a fine thing, but I noticed now, when www.zope.org was back up, that despite having logged in, as soon as I when to the above URL, I was "Guest" again, and unable to annotate the discussion... (no "edit" link, etc.) Maybe this is a symptom of operator failure? For now, however, I'll continue CC'ing the zope list, unless you specifically wish it to be shunted to the zope-dev list? Maybe the other zope users have an opinion on this as well? Thanks for taking the initiative in this regard, thanks to all at DC for the ongoing support, and thanks to the list for their reports! Let's all continue together towards the solution! -- Marcus

3 2

Can I create dtml to calculate a date 30 days ago?
by jpenny＠universal-fasteners.com 13 Apr '00

13 Apr '00

I would like to do the following: <dtml-call "REQUEST.set('magicdate', DateTime()-days)"> where days is a variable set in a form in a higher level web page. It does not work, complains about "bad operand for unary -". Is there a way in DTML to do this? (And if so, what is it?). I am usually pretty good at trying quoting variants until I stumble accross one that works, but I just can't find it this time. Thanks Jim

2 1

Re: Invisible instance bug with Sub ZClasses
by Alexandre Ratti 13 Apr '00

13 Apr '00

Hi Jason, At 12:00 12/04/2000 -0700, you wrote: >Date: Wed, 12 Apr 2000 12:57:50 -0400 >From: Jason Spisak <444(a)hiretechs.com> >Subject: [Zope-dev] Invisible instance bug with Sub ZClasses >In the Collector, tickets [1178], [1175], [1161] all refer to the same >bug. This seems to be a pretty significant set back to anyone using >ZClass to create an application.(Which is probably a high percentage) Is >this holding anyone else's process up majorly? It's only a problem with >2.1.6. I haven't checked it against CVS, has anyone else? Alexandre? No; I was using Zope 2.1.4 when I first ran into the problem. I haven't tried with any CVS version. Cheers. Alexandre >Jason Spisak >444(a)hiretechs.com

1 0

Z2.py is dying...
by Fabio Augusto Mazzarino 13 Apr '00

13 Apr '00

Hello folks. After some weeks of hard work trying to install nisUserFolder I discoverd that we use md5 password encryptation. Then, after some hours I've modified this way: from this: def authenticate(self, password, request): domains=self.getDomains() person = match(self.name,'passwd.byname') vals = split(person, ':') if vals[1][-1] == '\n': #name:pwd\n pwd = vals[1][:-1] else: pwd = vals[1] #normal way salt = vals[1][:2] #ye old nisUserFolder w/o md5 secret = crypt(password, salt) if domains: return (secret==pwd) and domainSpecMatch(domains, request) return secret==pwd to this: def authenticate(self, password, request): domains=self.getDomains() person = match(self.name,'passwd.byname') vals = split(person, ':') if vals[1][-1] == '\n': #name:pwd\n pwd = vals[1][:-1] else: pwd = vals[1] #normal way if vals[1][:3] == '$1$': #md5 way delim = find(vals[1], '$', 3) salt = vals[1][:delim] #$1$salt else: salt = vals[1][:2] #ye old nisUserFolder w/o md5 #salt = vals[1][:2] #ye old nisUserFolder w/o md5 secret = crypt(password, salt) if domains: return (secret==pwd) and domainSpecMatch(domains, request) return secret==pwd And now Z2.py lasts no more than 5 minutes. It simply dies without any warning, without any message at all. What can I do to validate these users *and* make Zope work correctly (yes, it used to work before nisUserFolder modification). Thanx. Fabio Augusto Mazzarino - mazza(a)radiumsystems.com.br P.S.: What is past tense for to ping?

2 1