Re: [Zope] Zope hanging: internal ZODB error?
Please continue to CC the list on this thread. Darran Edmundson wrote:
Thanks for the prompt response Michel.
Update your Catalog and this will go away.
Currently I don't have root access to the Zope machine and can't kill a runaway process - so if it's Friday evening and Zope needs a reboot, I'm stuffed until Monday morning. Needless to say, I took your advice with great trepidation - and it worked :-)
Is the problem here that my publicationCatalog was out of synch with the ZODB?
No.
I really need to know why this happened to avoid it in future.
So do I. Several people have reported this bug, but I cannot reproduce it. No one has been able to reproduce it or tell me how to reproduce it, therefore, I cannot fix it. The only thing I can tell you is that it has to do with ZClasses that catalog themselves and that it happens rarely and that updating your catalog allways fixes it. I suspect it has to do with poorly engineered ZClasses.
I don't dare execute the dtml below again out of work hours when I can ask the sysadmin for a restart. I'll try it again Monday and report back.
<dtml-with jdl124> <dtml-with publications> <dtml-in "objectValues()"> <dtml-var id><br> </dtml-in> </dtml-with> </dtml-with>
Hmmm... where is this method? Is it in jd1124?
Which method?
The method that contains this code. You are probably experiencing some sort of infinite loop. -Michel
On Fri, 24 Mar 2000, Michel Pelletier wrote:
it, therefore, I cannot fix it. The only thing I can tell you is that it has to do with ZClasses that catalog themselves and that it happens rarely and that updating your catalog allways fixes it. I suspect it has to do with poorly engineered ZClasses.
What would constitute a poorly engineered ZClass? I've seen this problem with a ZClass that is descended from just CatalogAware, has a few properties, and for which I've rewritten the Add and Edit methods to call reindex_object. I'm not sure how I could engineer this simple class better, but I don't really understand why I have to rewrite the Add and Edit methods to call reindex_object, so it could well be that there are improvements that could be made. In my case, I did not even do an update catalog. After adding a few additional objects, the error message went away on its own. (I didn't do a catalog update, because if I do that the meta data for the id field gets completely screwed up, so I stay well away from catalog update). I am running under SiteAccess, and I have a sneaking suspicion my problems orignate there. I'll be moving the database to a dedicated server soon and will remove SiteAccess. If I see the error again at that point I'll let you know. --RDM
"R. David Murray" wrote:
On Fri, 24 Mar 2000, Michel Pelletier wrote:
it, therefore, I cannot fix it. The only thing I can tell you is that it has to do with ZClasses that catalog themselves and that it happens rarely and that updating your catalog allways fixes it. I suspect it has to do with poorly engineered ZClasses.
What would constitute a poorly engineered ZClass?
It's just a suspicion, and as I noted in my previous mail I cant tell you constitutes a poorly engineered ZClass because I can't reproduce the bug. By 'poorly engineered' I mean both the possibility that the bug is manifest of the user createing the ZClass, _or_ that the ZClass implementation is broken. I did not mean to point fingers.
I've seen this problem with a ZClass that is descended from just CatalogAware, has a few properties, and for which I've rewritten the Add and Edit methods to call reindex_object.
Can you reproduce it deterministicly?
I'm not sure how I could engineer this simple class better, but I don't really understand why I have to rewrite the Add and Edit methods to call reindex_object,
Because when you change an object, you must inform the catalog that the object has change so it can update its indexes.
so it could well be that there are improvements that could be made.
In my case, I did not even do an update catalog. After adding a few additional objects, the error message went away on its own.
This is because one of your new objects filled in the missing hole, it may have made the problem go away, but it didn't fix it.
(I didn't do a catalog update, because if I do that the meta data for the id field gets completely screwed up, so I stay well away from catalog update).
This has never happened to me, can you reproduce this deterministicly also?
I am running under SiteAccess, and I have a sneaking suspicion my problems orignate there. I'll be moving the database to a dedicated server soon and will remove SiteAccess. If I see the error again at that point I'll let you know.
Please do. Thanks. -Michel
participants (2)
-
Michel Pelletier -
R. David Murray