May 2004 - Zope-Dev - Zope lists

RE: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage caused by errors
by Jean-Francois.Doyon＠CCRS.NRCan.gc.ca 20 May '04

20 May '04

Juan David, OK, 1.1.0a3 indeed suffers from the same problem, I'm going to take a closer look the the publishing mechanism to see if I can find anything relevant. Thanks, J.F. -----Original Message----- From: "J. David Ibáñez" [mailto:jdavid@itaapy.com] Sent: May 20, 2004 10:17 AM To: Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca Cc: tseaver(a)zope.com; brian(a)zope.com; chrism(a)plope.com; zope-dev(a)zope.org Subject: Re: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage caused by errors The "a" in 1.1.0a3 means "alpha". If the problem is in Localizer 1.0.1 I think it will be in 1.1.0a3 too. Yes, I have a site with a similar behaviour, unfortunately today the network connection is too slooow, so I can't test that site. I'm going to do some local tests, though. Yes, the problem might be the fact that "new_publish" does not catch exceptions to remove the request from the dictionary. Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca wrote: >Juan David, > >I'm using 1.0.1 ... I'm just abotu to try and test with 1.1.0a3 ... > >BTW, does that mean it's alpha software or something? is 1.1.0 stable? > >If the problem comes from Localizer I suspect this patch might be the cause: > >def new_publish(request, module_name, after_list, debug=0): > id = get_ident() > print "Localizer got thread id: " + str(id) > Publish._requests[id] = request > print "Request dict is now: " + str(Publish._requests) > x = Publish.old_publish(request, module_name, after_list, debug) > try: > del Publish._requests[id] > except KeyError: > # XXX > # Some people has reported that sometimes a KeyError exception is > # raised in the previous line, I haven't been able to reproduce it. > # This try/except clause seems to work. I'd prefer to understand > # what is happening. > LOG('Localizer', PROBLEM, > "The thread number %s don't has a request object associated." % >id) > except: > print "Localizer got an exception" > > return x > >What happens if an exception occurs here: > > x = Publish.old_publish(request, module_name, after_list, debug) > >?? > >If some clean up code is supposed to occur it might be held back by the fact >that >there's a reference to the request kept in the global dictionary ... >At least that's my theory :) >But then I'm mostly uneducated about the intricacies of exception handling >at this >level, though I've been forced to learn quickly :) > >I'd be curious to know at least if you can reproduce the leak by generating >loads >of errors on a Localizer enabled site? > >One option would also be to simply wrap it in a try:catch and see what >happens there >... But I noticed 1.1.0a3 uses a different model for wrapping the request, >so that >just might do the trick. > >Thanks for a very cool and useful product BTW. This is combination with the >TranslationService is saving me loads of time. > >Cheers, >J.F. > >-----Original Message----- >From: zope-dev-bounces(a)zope.org [mailto:zope-dev-bounces@zope.org]On >Behalf Of "J. David Ibáñez" >Sent: May 20, 2004 6:47 AM >To: Tres Seaver >Cc: Jean-Francois.Doyon(a)ccrs.nrcan.gc.ca; brian(a)zope.com; >chrism(a)plope.com; zope-dev(a)zope.org >Subject: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage caused by >errors > > > >Localizer (1.0.1) dynamically patches Zope, it stores a dictionary in >the module >"ZPublisher.Publish". The keys are integers, they are the values >returned by Python's >"thread.get_ident". The values are "ZPublisher.HTTPRequest.HTTPRequest" >instances, they are not acquisition wrappers. > >Jean-François, which Localizer version do you use? Just to be sure we >look at >the same code. > > > > -- J. David Ibáñez Founder and CTO of Itaapy <http://www.itaapy.com> 9 rue Darwin, 75018 Paris Tel +33 (0)1 42 23 67 45 / Fax +33 (0)1 53 28 27 88

1 0

RE: [Zope-dev] Preliminary findings: Zope 2.7 leakage caused by e rrors
by Jean-Francois.Doyon＠CCRS.NRCan.gc.ca 20 May '04

20 May '04

Dieter, Thanks yet again for all the valuable input. I've started tracking down/running into the whole ExtensionClasses instances/issues. As you suggest, the dict is probably help by BaseRequest.RequestContainer, which I've seen grow in parallel to the HTTPRequest refcounts ... Which seems to make sense. And as you suggest, as I've been doing this, I've been thinking I'm really looking forward to getting ri dof ExtensionClass, makes this kind of work much easier. The requests themselves look clean, but if they contain ExtensionClasses based instances gc wouldn't find them for the same reason. I've gotten far enough to be able to tell there's a variety of them. I suspect the instance the error occured ON is what's leaked (So if it's a CMFDocument, then that said Document ends up leaked). I was just getting to this yesterday, hopefully I'll solve that today. As Tres suggested, I'm going to go back to looking at Localizer ... It's the likliest suspect at this time. It's just hard for to test since pretty much everything I have depends on i18n PT's, and in some cases I have gettext() calls in Python code. Localizer "wraps" the Publish.publish, and I'm thinking that when exceptions occur in there Localizer needs to be aware of it and react accordingly, which it doesn't right now. The hunt goes on ... Cheers, J.F. -----Original Message----- From: Dieter Maurer [mailto:dieter@handshake.de] Sent: May 20, 2004 3:52 AM To: Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca Cc: zope-dev(a)zope.org; tseaver(a)zope.com; chrism(a)plope.com; brian(a)zope.com Subject: Re: [Zope-dev] Preliminary findings: Zope 2.7 leakage caused by errors Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca wrote at 2004-5-19 14:44 -0400: > ... >Right now I've focused on finding out why the Requests are still around. > >Using the gc module, I've found that all leaked requests are being held by a >dictionary. If I look at said dictionaries, this is what they might look >like: > >{'REQUEST': <HTTPRequest, >URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_v h >_site/francais/mapsatoz>}, > {'REQUEST': <HTTPRequest, >URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_v h >_site/francais/mapsatoz>}, These dictionaries look like the "instance dict"s of the "ZPublisher.BaseRequest.RequestContainer"s. When you have any cycle involving an AcquisitionWrapper, then its reference to the "RequestContainer" will keep this alive together with its instance dict. You may analyse the content of your requests. Do they contain acquisition wrapped objects (or other objects with (maybe indirect) references to this dict)? If not, "REQUEST" does not seem to be the root of your cycles but rather a side effect. More important notes: * When you see "AcquisitionWrapper"s in the reference information in "Control_Panel --> Debug Information", then there *must* also be other prominent ExtensionClass'es -- the "aq_base" of these wrappers. These classes may provide a valuable clue towards the cause of the cycles -- of global variables (by the way). * The reference information in "Control_Panel" covers only instance objects but not elementary Python data types. Thus, when cycles are caused by elementary Python objects, we may not directly see them in the list. GC's "DEBUG_LEAK" may provide some information. * The leaks may not be caused by cycles at all (though it is the most likely cause) but could result from a global cache containing references to acquisition wrapped objects. Such a cache should never exist -- global variables and class attributes must never directly or indirectly reference persistent objects -- as this results in nasty persistency bugs. Nevertheless, sometimes software is buggy. I noticed such a cache in Archetypes 1.3a2 (fixed in newer versions). .... >Said dictionary does not seem to be referred to by anything, at least not >anything the gc module can find (gc.get_referrers()). That's probably because "RequestContainer" is an ExtensionClass and ExtensionClasses are not yet (only from Zope 2.8 on) GC aware. > ... >Also I >understand zope.org suffers from this? :) Leaks can have innumerable causes. It is by no means clear that your leak and the one on Zope.org has the same cause. >Based on this information also, I have no reason to believe this is caused >by product code ... I have to guess it's a Zope bug? I do not observe leaks in my Zope installation -- even when I make an error stress test. This does not mean it could not be a Zope bug -- but it implies that such a bug does not surface regularly, at most under special conditions. >In some ways this is motivating me to reduce the number of errors that could >occur, but because ALL errors seems to cause the problem, I ultimately have >no control over it and under certain circumstances I suffer heavily from >this. 404's alone probably cause this (I'm plannign to test that >explicitely as well). It does not here.... Something is special with your installation -- maybe "Localizer" as Tres suggested, maybe another misbehaving product. -- Dieter

1 0

Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces
by Jim Fulton 19 May '04

19 May '04

Casey Duncan wrote: > On Wed, 19 May 2004 16:00:43 -0400 > Jim Fulton <jim(a)zope.com> wrote: > > >>I've posted two proposals: >> >> http://dev.zope.org/Zope3/TALESPathExpressionAdapters > > > I have to say I am not found of "*", I'm not attached to '*'. Feel free to suggest alternatives (other than ':', '/', '|', or '?'. Is that all ;) > but using the parenthesis to "cast" > the variable seems fairly natural and isn't colored by completelt > different meaning in other languages. > > So the example: > tal:content="x/y*foo.bar.baz/z" > > would be: > tal:content="x/(foo.bar.baz)y/z" Yup > Which seems reasonable. The dotted notation seems ok, but it implies > that this notation is recognized in general in path expressions which is > confusing because it isn't. If we didn't use dots then it might look > like: > tal:content="x/(modules/foo/bar/baz)y/z" I'm not sure what you mean here. If the thing in the parens was a path expression, it would be: x/(modules/foo.bar/baz)y/z IOW, modules excepts dotted names. > If the thing in the parenthesis is just another path expression, that > mitigates the need for namespaces IMO. The above could then become: > tal:define="baz modules/foo/bar/baz" > tal:content="x/(baz)y/z" True, but then, the obvious syntax would be: x/baz(y)/z which is the top of a slippery slope. :) It would also make it harder to provide predefined adapter names. We'd like to be able to define some adapters (e.g. 'zope', 'format', etc.) in ZCML and let people just use them in ZPT without having to use defines. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 1

Re: [ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please)
by alex＠halogen-dg.com 19 May '04

19 May '04

Hi Chris, On Wed, 3 Mar 2004, Chris McDonough wrote: > With this text: > > <zodb_db temporary> > # Temporary storage database (for sessions) > <filestorage> > path $INSTANCE/var/Sessions.fs > </filestorage> > mount-point /temp_folder > container-class Products.TemporaryFolder.TemporaryContainer > </zodb_db> Installed. I had to install new zope instance first, then import old content via zexp & recreate manually all admins. Because when you change the running zope config in Zope 2.7.0 it has no impact on temp_folder - Sessions.fs is not created when the temporary storage was already in place. Lets see, next test will be on Monday, many users come only on working days. I also got many complatins from customer, so I wrote a test suite which is logging to a site each 2 minutes, and if there are problem, it sends emails to all of admins, so they come and restart zope. With prev. Transience, when this keyError appear, it was seen only by 1,2,3 users. With new Transience, when error starts to appear, nobody is able to see any page which uses Session - all sessions became broken. I am monitoring site now, and will tell you about the results. -- Alex V. Koval http://www.halogen-dg.com/ http://www.zwarehouse.org/

15 68

Conflict errors on BDBMinimal storage
by Gerhard Schmidt 19 May '04

19 May '04

Hi, whe are running portal unter zope2.7 with one zeo server and six frontend application servers. I have set up zeo to server two storages <filestorage main> path $INSTANCE_HOME/var/Data.fs </filestorage> <minimalstorage temp> envdir $INSTANCE_HOME/var/session </minimalstorage> temp should provide an shared session. But when is set up the frontends to use temp as /temp_folder, we see many ZODB conflict errors. The performance decreases and PosErrors appear quite often. Is there any why to get a shared session working. Bye Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | PGP Public Key Fischbachweg 3 | Privat: estartu(a)augusta.de | auf Anfrage/ 86856 Hiltenfingen | Dienst: schmidt(a)ze.tu-muenchen.de | on request

8 20

Threads dying on zope 2.7.0 on one Zeo setup, ZServer exception
by Heimo Laukkanen 18 May '04

18 May '04

Hi ya, I noticed some weird bahivour that was bringing a setup down on our servers on testing installation. In our setup we create development sandboxes with makefile and in similar fashion also testing/production servers. Our testing/production setup has a little bit different config files where from standard config all the commented out lines have been removed. Also compared to development instances the instance home is in other place. Other than that setups are same. At the moment with testing setup under load test ZServer dies - leaving all but one thread at almost 0% cpu and that one thread working in high loads of 90%. Testing similar zeo-setup with development instances do not produce this. We are a bit scared on this, since we do not have clue on what causes following behaviour - and eventhough we see that we can get it to work, we would like to have an idea on what might be behind this - so that it does not bite our butt again. Below is log snip and traceback of the exceptions when other threads go down. In log-file we get: 2004-05-17T16:47:17 ERROR(200) ZServer uncaptured python exception, closing channel <ZServer.HTTPServer.zhttp_channel connected 127.0.0.1:47855 at 0x42fdb36c channel#: 589 requests:> (socket.error:(104, 'Connection reset by peer') [/opt/portaali/ContentManagement-1.0/python-2.3.3/lib/python2.3/asynchat.py|initiate_send|218] [/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZServer/medusa/http_server.py|send|417] [/opt/portaali/ContentManagement-1.0/python-2.3.3/lib/python2.3/asyncore.py|send|337]) 2004-05-17T16:48:49 ERROR(200) ZServer uncaptured python exception, closing channel <ZServer.HTTPServer.zhttp_channel connected 127.0.0.1:47924 at 0x430538ac channel#: 651 requests:> (socket.error:(104, 'Connection reset by peer') [/opt/portaali/ContentManagement-1.0/python-2.3.3/lib/python2.3/asynchat.py|initiate_send|218] [/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZServer/medusa/http_server.py|send|417] [/opt/portaali/ContentManagement-1.0/python-2.3.3/lib/python2.3/asyncore.py|send|337]) 2004-05-17T16:50:05 ERROR(200) ZServer uncaptured python exception, closing channel <ZServer.HTTPServer.zhttp_channel connected 127.0.0.1:47961 at 0x42f3ba4c channel#: 683 requests:> (socket.error:(104, 'Connection reset by peer') [/opt/portaali/ContentManagement-1.0/python-2.3.3/lib/python2.3/asynchat.py|initiate_send|218] [/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZServer/medusa/http_server.py|send|417] [/opt/portaali/ContentManagement-1.0/python-2.3.3/lib/python2.3/asyncore.py|send|337]) In tracback we will get: 2004-05-18T11:44:14 INFO(0) Zope Ready to handle requests Unhandled exception in thread started by <class ZServer.PubCore.ZServerPublisher.ZServerPublisher at 0x405435cc> Traceback (most recent call last): File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZServer/PubCore/ZServerPublisher.py", line 23, in __init__ response=response) File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZPublisher/Publish.py", line 372, in publish_module environ, debug, request, response) File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZPublisher/Publish.py", line 173, in publish_module_standard request.response.exception() AttributeError: 'NoneType' object has no attribute 'exception' Unhandled exception in thread started by <class ZServer.PubCore.ZServerPublisher.ZServerPublisher at 0x405435cc> Traceback (most recent call last): File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZServer/PubCore/ZServerPublisher.py", line 23, in __init__ response=response) File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZPublisher/Publish.py", line 372, in publish_module environ, debug, request, response) File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZPublisher/Publish.py", line 173, in publish_module_standard request.response.exception() AttributeError: 'NoneType' object has no attribute 'exception' Unhandled exception in thread started by <class ZServer.PubCore.ZServerPublisher.ZServerPublisher at 0x405435cc> Traceback (most recent call last): File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZServer/PubCore/ZServerPublisher.py", line 23, in __init__ response=response) File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZPublisher/Publish.py", line 372, in publish_module environ, debug, request, response) File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZPublisher/Publish.py", line 173, in publish_module_standard request.response.exception() AttributeError: 'NoneType' object has no attribute 'exception' Unhandled exception in thread started by <class ZServer.PubCore.ZServerPublisher.ZServerPublisher at 0x405435cc> Traceback (most recent call last): File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZServer/PubCore/ZServerPublisher.py", line 23, in __init__ response=response) File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZPublisher/Publish.py", line 372, in publish_module environ, debug, request, response) File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZPublisher/Publish.py", line 173, in publish_module_standard request.response.exception() AttributeError: 'NoneType' object has no attribute 'exception' Unhandled exception in thread started by <class ZServer.PubCore.ZServerPublisher.ZServerPublisher at 0x405435cc> Traceback (most recent call last): File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZServer/PubCore/ZServerPublisher.py", line 23, in __init__ response=response) File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZPublisher/Publish.py", line 372, in publish_module environ, debug, request, response) File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZPublisher/Publish.py", line 173, in publish_module_standard request.response.exception() AttributeError: 'NoneType' object has no attribute 'exception' Unhandled exception in thread started by <class ZServer.PubCore.ZServerPublisher.ZServerPublisher at 0x405435cc> Traceback (most recent call last): File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZServer/PubCore/ZServerPublisher.py", line 23, in __init__ response=response) File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZPublisher/Publish.py", line 372, in publish_module environ, debug, request, response) File "/opt/portaali/ContentManagement-1.0/zope-2.7.0/lib/python/ZPublisher/Publish.py", line 173, in publish_module_standard request.response.exception() AttributeError: 'NoneType' object has no attribute 'exception' -huima

2 1

When is the configuration read in Zope 2.7?
by Andreas Jung 17 May '04

17 May '04

During the product registration the ZReST product is imported. on the module level it contains default_output_encoding = getConfiguration().rest_output_encoding or default_enc I would inspect that at this point the configuration from zope.conf has been read and rest_output_encoding should be available but instead the following AttributeError occurs. Any ideas why? Traceback (most recent call last): File "test.py", line 490, in get_suite mod = package_import(modname) File "test.py", line 464, in package_import mod = __import__(modname) File "/home/chrism/opt/tests/sandbox/Zope/lib/python/AccessControl/tests/testUserFolder.py", line 24, in ? Zope.startup() File "/home/chrism/opt/tests/sandbox/Zope/lib/python/Zope/__init__.py", line 46, in startup _startup() File "/home/chrism/opt/tests/sandbox/Zope/lib/python/Zope/App/startup.py", line 45, in startup OFS.Application.import_products() File "/home/chrism/opt/tests/sandbox/Zope/lib/python/OFS/Application.py", line 631, in import_products import_product(product_dir, product_name, raise_exc=debug_mode) File "/home/chrism/opt/tests/sandbox/Zope/lib/python/OFS/Application.py", line 654, in import_product product=__import__(pname, global_dict, global_dict, silly) File "/home/chrism/opt/tests/sandbox/Zope/lib/python/Products/ZReST/__init__.py", line 7, in ? import ZReST File "/home/chrism/opt/tests/sandbox/Zope/lib/python/Products/ZReST/ZReST.py", line 27, in ? default_output_encoding = getConfiguration().rest_output_encoding or default_enc AttributeError: DefaultConfiguration instance has no attribute 'rest_output_encoding' Andreas -- Andreas Jung -------------------------------- www.zopyx.com Software-Entwicklung und Consulting Andreas Jung

5 12

Getting Zope 2.7 trunk working
by Erik A.Dahl 17 May '04

17 May '04

I'm trying to do work off of the 2.7 trunk in svn. After doing: svn svn://svn.zope.org/repos/main/Zope/trunk zope ./configure make make instance when I run bin/zopectl debug I get the following, what am I doing wrong? No handlers could be found for logger "Init" Starting debugger (the name "app" is bound to the top-level Zope object) 2004-05-17 11:33:09 WARNING Init Ambiguous name for method of OFS.Uninstalled.BrokenClass: 'manage' != 'manage_main' 2004-05-17 11:33:09 WARNING Init Ambiguous name for method of OFS.Uninstalled.BrokenClass: 'manage' != 'manage_workspace' 2004-05-17 11:33:10 ERROR Zope.ZODBMountPoint Failed to mount database. exceptions.AttributeError ('Connection' object has no attribute '_getMountedConnection') Traceback (most recent call last): File "/home/edahl/src/zope/lib/python/Products/ZODBMountPoint/Mount.py", line 93, in _getOrOpenObject conn = self._getMountedConnection(anyjar) File "/home/edahl/src/zope/lib/python/Products/ZODBMountPoint/Mount.py", line 71, in _getMountedConnection conn = anyjar._getMountedConnection(db_name) AttributeError: 'Connection' object has no attribute '_getMountedConnection' 2004-05-17 11:33:10 ERROR Zope Default Object Creation Could not add a /temp_folder mount point due to an error. Traceback (most recent call last): File "/home/edahl/src/zope/lib/python/OFS/Application.py", line 358, in install_tempfolder_and_sdc manage_addMounts(app, ('/temp_folder',)) File "/home/edahl/src/zope/lib/python/Products/ZODBMountPoint/ MountedObject.py", line 283, in manage_addMounts mo._test(app) File "/home/edahl/src/zope/lib/python/Products/ZODBMountPoint/Mount.py", line 126, in _test self._getOrOpenObject(parent) File "/home/edahl/src/zope/lib/python/Products/ZODBMountPoint/Mount.py", line 93, in _getOrOpenObject conn = self._getMountedConnection(anyjar) File "/home/edahl/src/zope/lib/python/Products/ZODBMountPoint/Mount.py", line 71, in _getMountedConnection conn = anyjar._getMountedConnection(db_name) AttributeError: 'Connection' object has no attribute '_getMountedConnection' >>>

3 2

Getting Zope 2.7 trunk working
by Erik A.Dahl 17 May '04

17 May '04

I'm trying to do work off of the 2.7 trunk in svn. After doing: svn svn://svn.zope.org/repos/main/Zope/trunk zope ./configure make make instance when I run bin/zopectl debug I get the following, what am I doing wrong? No handlers could be found for logger "Init" Starting debugger (the name "app" is bound to the top-level Zope object) 2004-05-17 11:33:09 WARNING Init Ambiguous name for method of OFS.Uninstalled.BrokenClass: 'manage' != 'manage_main' 2004-05-17 11:33:09 WARNING Init Ambiguous name for method of OFS.Uninstalled.BrokenClass: 'manage' != 'manage_workspace' 2004-05-17 11:33:10 ERROR Zope.ZODBMountPoint Failed to mount database. exceptions.AttributeError ('Connection' object has no attribute '_getMountedConnection') Traceback (most recent call last): File "/home/edahl/src/zope/lib/python/Products/ZODBMountPoint/Mount.py", line 93, in _getOrOpenObject conn = self._getMountedConnection(anyjar) File "/home/edahl/src/zope/lib/python/Products/ZODBMountPoint/Mount.py", line 71, in _getMountedConnection conn = anyjar._getMountedConnection(db_name) AttributeError: 'Connection' object has no attribute '_getMountedConnection' 2004-05-17 11:33:10 ERROR Zope Default Object Creation Could not add a /temp_folder mount point due to an error. Traceback (most recent call last): File "/home/edahl/src/zope/lib/python/OFS/Application.py", line 358, in install_tempfolder_and_sdc manage_addMounts(app, ('/temp_folder',)) File "/home/edahl/src/zope/lib/python/Products/ZODBMountPoint/ MountedObject.py", line 283, in manage_addMounts mo._test(app) File "/home/edahl/src/zope/lib/python/Products/ZODBMountPoint/Mount.py", line 126, in _test self._getOrOpenObject(parent) File "/home/edahl/src/zope/lib/python/Products/ZODBMountPoint/Mount.py", line 93, in _getOrOpenObject conn = self._getMountedConnection(anyjar) File "/home/edahl/src/zope/lib/python/Products/ZODBMountPoint/Mount.py", line 71, in _getMountedConnection conn = anyjar._getMountedConnection(db_name) AttributeError: 'Connection' object has no attribute '_getMountedConnection' >>>

2 1

can't resolve/follow up on collector issues?
by Chris McDonough 17 May '04

17 May '04

Not sure what has changed on Zope.org but the account that I typically use to resolve/follow up on collector issues ("mcdonc") is no longer able to do so (it appears I no longer have access to do sol; I can browse and read the issues fine). Anyone have any ideas?

1 1