- Zope - Zope lists

Zope Error.
by Ramon Aseniero 13 May '04

13 May '04

Hi All, I got this error messages any idea what caused it and how I can fix it? Site Error An error was encountered while publishing this resource. error Sorry, a site error occurred. Traceback (innermost last): ********Module ZPublisher.Publish, line 150, in publish_module ********Module Products.Localizer, line 58, in new_publish ********Module ZPublisher.Publish, line 114, in publish ********Module Zope.App.startup, line 202, in zpublisher_exception_hook ********Module ZPublisher.Publish, line 98, in publish ********Module ZPublisher.mapply, line 88, in mapply ********Module ZPublisher.Publish, line 39, in call_object ********Module Shared.DC.Scripts.Bindings, line 306, in __call__ ********Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec ********Module Products.PageTemplates.ZopePageTemplate, line 228, in _exec ********Module Products.PageTemplates.PageTemplate, line 95, in pt_render <ZopePageTemplate at /clubhouse/login_form> ********Module TAL.TALInterpreter, line 200, in __call__ ********Module TAL.TALInterpreter, line 244, in interpret ********Module TAL.TALInterpreter, line 703, in do_useMacro ********Module TAL.TALInterpreter, line 244, in interpret ********Module TAL.TALInterpreter, line 726, in do_defineSlot ********Module TAL.TALInterpreter, line 244, in interpret ********Module TAL.TALInterpreter, line 669, in do_condition ********Module TAL.TALInterpreter, line 244, in interpret ********Module TAL.TALInterpreter, line 567, in do_insertTranslation ********Module TAL.TALInterpreter, line 655, in translate ********Module Products.PageTemplates.TALES, line 258, in translate ********Module Products.TranslationService.PlacefulTranslationService, line 65, in translate ********Module Products.TranslationService.PlacefulTranslationService, line 170, in translate ********Module Products.TranslationService.Domain, line 86, in translate ********Module Products.TranslationService.LocalizerMessageCatalog, line 77, in queryMessage ********Module Products.Localizer.MessageCatalog, line 165, in gettext ********Module ZODB.Connection, line 551, in setstate ********Module ZODB.FileStorage, line 645, in load ********Module ZODB.FileStorage, line 623, in _load error: unpack str size does not match format (Also, an error occurred while attempting to render the standard error message.) Troubleshooting Suggestions ********The URL may be incorrect. ********The parameters passed to this resource may be incorrect. ********A resource that this resource relies on may be encountering an error. For more detailed information about the error, please refer to the error log. If the error persists please contact the site maintainer. Thank you for your patience. Thanks, Ramon

1 0

Mysterious Database Error
by Asad Habib 13 May '04

13 May '04

Hello, I am trying to add a record to a MySQL database using a Z SQL method. The Z SQL method works fine and I have tested it by itself. Also, when called from a DTML method the Z SQL method adds the record to the database but Zope returns the following error: Site Error An error was encountered while publishing this resource. _mysql_exceptions.NotSupportedError Sorry, a site error occurred. Traceback (innermost last): * Module ZPublisher.Publish, line 163, in publish_module_standard * Module Products.PlacelessTranslationService.PatchStringIO, line 45, in new_publish * Module ZPublisher.Publish, line 108, in publish * Module Zope.App.startup, line 226, in abort * Module ZODB.Transaction, line 134, in abort * Module Shared.DC.ZRDB.TM, line 63, in abort * Module Products.ZMySQLDA.db, line 328, in _abort NotSupportedError: (1196, "Warning: Some non-transactional changed tables couldn't be rolled back") I have checked the Zope error log but this error is not logged. Any help would be greatly appreciated. Thanks. - Asad

4 7

RE: Leaking HTTP requests (was: RE: [Zope] Leaking Acquisition.Im plic itAcquirerWrapper)
by Jean-Francois.Doyon＠CCRS.NRCan.gc.ca 13 May '04

13 May '04

Unfortunately, I can't easily get rid of Localizer. I use TranslationService + Localizer on the entire site for all of my skins and so on ... I've managed to leak a few HTTP Requests on my test box, but I still have no idea how/why. I simply hit the homepage of my site repeatedly using JMeter, and got a few new references that are sticking around. They don't all stick around though, and it doesn't seem to necessarily be only the first time I hit a page that the refcount goes up, and I can't detect any pattern to it ... When I test manually, some lost references appear, and then they stop appearing, and then sometime later a couple more appear, and so on. My events log has nothing in it, neither does the error_log. I have in the past seen a few entries in my events log file such as: "Localizer The thread number 5126 don't has a request object associated." But again, there's very few of those compared to the amount of leakage occuring. Alright, I guess I'll go look in the Localizer code see if I notice anything and otherwise keep at it ... I REALLY hate having to go the "restart every night" route ... J.F. -----Original Message----- From: Stefan H. Holek [mailto:stefan@epy.co.at] Sent: May 13, 2004 3:37 PM To: Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca Cc: zope(a)zope.org Subject: Re: Leaking HTTP requests (was: RE: [Zope] Leaking Acquisition.Implic itAcquirerWrapper) This confirms my suspicion somewhat that the global request patch is to blame. IIRC Localizer uses this, doesn't it? Do you have the possibility to test without the (monkey?) patch, or without Localizer entirely? Huima has just recently reported pretty much the same bug and he is using PTS, which again utilizes the global request patch (I think). Stefan On Donnerstag, Mai 13, 2004, at 21:31 Europe/Vienna, Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca wrote: > Oh, wait a minute ... > > Looks like I'm actually leaking HTTP requests! > > Class May 12, 2004 5:08 pm May 13, 2004 3:26 pm Delta > Acquisition.ImplicitAcquirerWrapper 7190 138920 +131730 > ZPublisher.HTTPRequest.HTTPRequest 352 18123 +17771 > ZPublisher.BaseRequest.RequestContainer 329 18095 +17766 > ZServer.HTTPResponse.ZServerHTTPResponse 338 18103 +17765 > > I saw some traffic on this same topic about archetypes & plone ... > > Hopefully I'll be able to track this down more easily than wrapper > problems. > > Still any input will be appreciated, tracking down memory leaks always > seems > like black magic to me :P > > Thanks, > J.F. > > -- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/

1 0

Leaking Acquisition.ImplicitAcquirerWrapper
by Jean-Francois.Doyon＠CCRS.NRCan.gc.ca 13 May '04

13 May '04

Hello, I'm not familiar enough with the acquistion wrappers to know what might be causing this, but it looks like my refcount for Acquisition.ImplicitAcquirerWrapper grows out of control ! Acquisition.ImplicitAcquirerWrapper 7190 120012 +112822 This is over ~27 hours ... Normally if I stare long enough at it it seems to be happy hovering in the 15-20K range ... I walk in this morning and see this. It's not the first time either ... I've noticed on a few occasions this occuring and the refcount topping 200K ... And Zope's memory usage growing and growing, even though the database info shows the same number of objects in cache, and the same number of ghost objects. I'm not sure how "consistent" it is however ... I'm wondering if there's some specific even that triggers this leak ... It seems table in the minutes/hour after restarting. The other thing is I'm quite certain I do nothing "weird" as far as acquisition goes. The only thing I do is use aq_explicit in a few places, either in Python code or in PT's. Other than that, I never mess with it. Can anybody suggest ways to find out where this might be coming from? If they were some of my own classes I'd have an idea ... but in thise case ... Any help would be most appreciated, this is seriously hurting the stability/performance and uptime of our site. I'm using Zope 2.7 w/ python 2.3.3 on RH7.3 with - CMF 1.4.2 - TranslationService - Localizer - mxmRelations - ZPsycopgDA And my custom products Thanks, Jean-François Doyon Internet Service Development and Systems Support / Spécialiste de dèveloppements internet et soutien technique Canada Centre for Remote Sensing / Centre Canadien de télédétection Natural Resources Canada / Ressources naturelles Canada http://atlas.gc.ca Tel./Tél. : (613) 992-4902 Fax: (613) 947-2410

3 2

Change the class of a Zope object
by Max M 13 May '04

13 May '04

I have a bunch of objects in the ZODB that I need to convert to other objects. The new object have the same meta_type and the same attributes. But they are of a new class. So I thought that I could simply assign a new class. I tried assigning the new class to __class__ but that didn't work. Like:: obj.__class__ = SomeNewClass I suspect that is because I am assigning it to an aquisition wrapper. But I am not shure. Would I need to do something like? base = obj.aq_base base.__class__ = SomeNewClass -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science

3 2

accelerated http cache manager and refresh header
by Gerald John M. Manipon 13 May '04

13 May '04

Hello, I have a ZPT containing a form which, once verified, spawns a thread that does some long-running processing. The initial thread then redirects to another ZPT which has the following code: <tal:block replace="python: request.RESPONSE.appendHeader('REFRESH',5)" /> Still processing... Finished processing. Click <a tal:attributes="href python:here.getSessionData(request.SESSION.id,'ncFile')" href="dummy">here</a> to download the NetCDF file. Click <a tal:attributes="href python: here.getSessionData(request.SESSION.id,'mpegUrl')" href="dummy">here</a> for mpeg movie of matchup plots. Click <a tal:attributes="href string: index_html" href="dummy">here</a> to start over. Encountered an error processing your request: Click <a tal:attributes="href string: index_html" href="dummy">here</a> to start over. Basically what is happening is that the long-running process thread is updating the status of the processing via the here.setSessionData() external method which I've written (essentially using ZODB keyed by session id). At the same time, this ZPT is refreshing until the status value is either -1 (long-running process finished successfully) or -2 (long-running process failed). This works fine, however, I have a lot of images on this ZPT and they fail to be cached by the browser. Other pages that use the same images get them fine from the browser cache or a 304 response from the server. I am using an accelerated http cache manager for the images and have taken note to represent them as absolute url's in my templates. Is there a way to get the images cached on the refreshing? Any help is greatly appreciated. Gerald

2 1

aq_inner and acquisition by containment only
by Stefan Bund 13 May '04

13 May '04

Hi list, while solving a somewhat intricate acquisition problem, I came discovered, that the statement, that aq_inner will return an object wrapped by containment only seems to be incorrect. Here is the simplified scenario to show this: Let a and c be attributes of x, let b be an attribute of a. Then x.a.c.a.b is the acquisition tree (as shown in Zope 2.7.0 using a little tool akin showaq) O-[b] | O-O-[a] | | | [x] | O-O-[c] | | | [x] | O-[a] | [x] (self goes to the right, parent down). The important thing is, that aq_inner of this is the same tree. I would have expexted to get the reduced tree O-[b] | O-[a] | [x] but looking at the first tree, it is obvious, why this is not the case. The Documentation says, that ( X o Y ) o ( Y o Z ) is simplified to X o ( Y o Z ). While working out the expression, I could find, that this simplification will close to the end simplify the b o ( a o x ) subtree away, since the next expression starts with ( a o x ). This leaves me a little bit uneasy: when searching x.a.c.a.b.aq_inner, c will be searched even though it is *not* in the containment path of b ! I would very much like a comment on this ... Is this known behavior? Should I have expected this? Stefan. -- -- *DON'T* TRY TO REACH ME DIRECTLY AT ABOVE EMAIL ADDRESS. Any reply -- received off-list at that address will be *silently* and -- *unconditionally* dropped. You can attribute this inconvenience to -- the proliferation of spammers on the Internet. I hope, you can -- understand my position and accept my counter measures.

2 3

case-independant catalog sorting
by Marc Lindahl 13 May '04

13 May '04

Does anyone know how to get a sort on a (zcatalog) FieldIndex to be case-independent (case-folding)?

3 7

RE: Leaking HTTP requests (was: RE: [Zope] Leaking Acquisition.Im plic itAcquirerWrapper)
by Jean-Francois.Doyon＠CCRS.NRCan.gc.ca 13 May '04

13 May '04

I do indeed use Localizer. I have a second instance of the Zope/Product configuration on a seperate machine, and so far I've been unable to replicate the problem. One thing I wanted to do was look at my REQUEST.set to see if that could cause problems. As for this global request patch, I'm not sure what you mean ... The test instance also uses Localizer and doesn't seem to suffer from the problem. The main thing here is that I'm not testing under load, just manually, trying to track down which actions might trigger refcounts. What's this patch exactly ? I do some monkey patching (Quite a bit actually, more than I should!) but nothing that messes with the request/response system. I have one place that uses REQUEST.set with wrapped objects ... based on what I've seen in some mailing list archives and from Dieter, this could very well be the cause ... (Not sure though, I used to have this on my previous site also, and never noticed it leaking ...) Thanks again for the assistance, it's proving very helpful :) J.F. -----Original Message----- From: Stefan H. Holek [mailto:stefan@epy.co.at] Sent: May 13, 2004 3:37 PM To: Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca Cc: zope(a)zope.org Subject: Re: Leaking HTTP requests (was: RE: [Zope] Leaking Acquisition.Implic itAcquirerWrapper) This confirms my suspicion somewhat that the global request patch is to blame. IIRC Localizer uses this, doesn't it? Do you have the possibility to test without the (monkey?) patch, or without Localizer entirely? Huima has just recently reported pretty much the same bug and he is using PTS, which again utilizes the global request patch (I think). Stefan On Donnerstag, Mai 13, 2004, at 21:31 Europe/Vienna, Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca wrote: > Oh, wait a minute ... > > Looks like I'm actually leaking HTTP requests! > > Class May 12, 2004 5:08 pm May 13, 2004 3:26 pm Delta > Acquisition.ImplicitAcquirerWrapper 7190 138920 +131730 > ZPublisher.HTTPRequest.HTTPRequest 352 18123 +17771 > ZPublisher.BaseRequest.RequestContainer 329 18095 +17766 > ZServer.HTTPResponse.ZServerHTTPResponse 338 18103 +17765 > > I saw some traffic on this same topic about archetypes & plone ... > > Hopefully I'll be able to track this down more easily than wrapper > problems. > > Still any input will be appreciated, tracking down memory leaks always > seems > like black magic to me :P > > Thanks, > J.F. > > -- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/

1 0

RE: [Zope] Leaking Acquisition.ImplicitAcquirerWrapper
by Jean-Francois.Doyon＠CCRS.NRCan.gc.ca 13 May '04

13 May '04

Stefan, Hmmm actually yes ... Not quite as high as the wrapper, but higher than I'd expect, right this moment I've got 124219 for the wrapper and 48965 for DateTime ... I use standard user folders everywhere, I don't do anything special with them ... So I have one in the root and one in each of two CMF instances. I removed the "Members" folder ... I have about 4 or 5 users in each, most access to the site is anonymous. Although now that you say it, it'd be interesting to see if removing user-based/authenticated access solves the problem. I've been trying to replicate the problem on a second copy of the site without success ... But then I never authenticated against it other than through the ZMI ... I'm looking forward to your response now that you've peaked my curiosity :) Thanks for the help, J.F. -----Original Message----- From: zope-bounces(a)zope.org [mailto:zope-bounces@zope.org]On Behalf Of Stefan H. Holek Sent: May 13, 2004 1:00 PM To: Jean-Francois.Doyon(a)ccrs.nrcan.gc.ca Cc: zope(a)zope.org Subject: Re: [Zope] Leaking Acquisition.ImplicitAcquirerWrapper a) Are you also seeing high refcounts for DateTime objects? b) Which user folder do you have? Stefan On Donnerstag, Mai 13, 2004, at 17:02 Europe/Vienna, Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca wrote: > I'm using Zope 2.7 w/ python 2.3.3 on RH7.3 with > - CMF 1.4.2 > - TranslationService > - Localizer > - mxmRelations > - ZPsycopgDA > -- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/ _______________________________________________ Zope maillist - Zope(a)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 )

1 0