[Zope-dev] Sync.Synchronized and ever increasing refcounts on 2.2.4
Hi all, In my Zope site I have classes derived from the mixin Sync.Synchronized, because the objects derived from my classes must be thread-safe. Lately I've being experiencing serious memory leaks, with the result that after a couple of days Zopes memory usage reaches a couple of hundred megabytes in size, and Zope stops responding. In an attempt to track down the problem, I have been using the Zope debug section of the management interface, and I noticed that the refcount of Sync.Synchronized increases by about 200 everytime my site receives a get request. These reference counts never decrease. To help me understand the problem, I wrote a small test harness consisting of two files. The first, test1.py, looks like this: import Sync class foo(Sync.Synchronized): def __init__(self): print 'constuctor' def bar(self): print 'wibble' # Create a singleton object. There should only be one of these. foo_ob=foo() ## end of test1.py The second file, test.py, looks like this: import sys,Sync import test1 count=0 while 1: count=count+1 # call method bar on object foo_ob. test1.foo_ob.bar() print '%d - %d' % (count, sys.getrefcount(Sync.Synchronized)) ## end of test.py This code just imports test1, and makes lots of calls to the bar() method of the single foo_ob. The results of running test.py is constuctor wibble 1 - 11 wibble 2 - 12 wibble 3 - 13 wibble 4 - 14 wibble 5 - 15 wibble 6 - 16 wibble 7 - 17 wibble 8 - 18 wibble 9 - 19 wibble 10 - 20 wibble 11 - 21 wibble 12 - 22 wibble 13 - 23 wibble 14 - 24 wibble 15 - 25 wibble 16 - 26 wibble 17 - 27 wibble 18 - 28 wibble 19 - 29 wibble 20 - 30 wibble 21 - 31 wibble 22 - 32 wibble 23 - 33 wibble 24 - 34 wibble 25 - 35 wibble 26 - 36 wibble 27 - 37 wibble 28 - 38 wibble 29 - 39 Note how the refcount for Sync.Synchronized keeps increasing. I searched on Google about this, and found this message: http://cvs.zope.org/Zope/lib/python/ts_regex.py?sortby=log which implies that there was a problem with refcounts. So, finally, we come to the question, or rather questions, since there are two: 1. Why does the refcount of Sync.Synchronized keep increasing? 2. Am I chasing a red herring here? That is, does the Top Refcounts part of the Zope Debug screen merely show that there is one instance of an object, and N references, and consequently nothing to worry about?. If so, is there a way I can find out how many real instances there are? Any advice greatly appreciated. Thanks in advance, Noel. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
RE: [Zope-dev] standard_error_message and displaying non-html content.
I have now put the first (rough) draft of a proposal up on dev.zope.org. Please feel free to comment/modify/add suggestions. If anyone has a specific problem with standard_error_message which my proposal does not address, please feel free to contact me. I will be away from the office for the next two weeks, and won't be reading email very often, so I won't be able to contribute much for a while. Trevor Toenjes writes: I wanted to throw 2 cents in to this thread from my previous problems/questions about error_message. I think they are slightly related. Maybe someone can filter my newbie-isms and use some of this in the Dogbowl. I would like to have more control over the standard_error_message auto-rendering of error_message and error_tb. These should be treated more like typical methods in Zope to be consistent with everything else. (like standard_html_header) ;) -Trevor What is error_message? Where does the autoformatting come from, and how do I alter it? Can I modify it to just grab the error and not all the other Zope stuff? You can't, as far as I can see. I have included in my proposal that the traceback information should be html free. Why is this so stealthy compared to the rest of Zope? I don't think it's stealthy. The problem is that it is assumed you will be targetting web browsers. Why should I have to turn off debugging for tracebacks to be commented out in the HTML? With my Zope understanding so far...if it is an object, then I can include it or not in my standard_error_message. So why is it hardcoded in Zope? Example: If I have error_tb in my standard_error_message, then it renders, if not - it's hidden. Current Zope renders it anyway. Why isn't it treated like an object like the rest of Zope? Part of the problem here is that Zope has to handle the case where standard_error_message raises an exception. If that happens, where does Zope get it's error response. To handle this case, ZPublisher/HTTPResponse.py contains a copy of the standard Zope traceback, and uses this if an error occurs during standard_error_message. Is there a library of these error messages that can be modified to provide better information for users to find what they are looking for. They come from somewhere? Not sure that there is a library as such. At least some of them are defined in ZPublisher/HTTPResponse.py, but others come from whatever traceback occurred. Formulator allows you to customize your error messages. It would be great if Zope_Error handling were that friendly. Can't comment on Formulator - never used it. Please look at my proposal on dev.zope.org and see if it addresses your particular case - if not, please add a comment or email me. Steve Alexander writes: seb bacon wrote: I don't believe there is a clean way. I've changed the source not to display its own html at all. It's not nice, but I suppose that's the benefit of OSS. Is there a FishBowl proposal on remedying this? If not, there should be one. Perhaps someone who has this itch to scratch can get the ball rolling? First, thanks for the quick response. Secondly, I would be willing to start this process, but my knowledge of Zope internals is patchy at best, so I might not be the best person for this. Still, if no-one else wants to, I will give it a go. Just to clarify, I am only concerned at present with the code in HTTPResponse that, in the case of an exception, scans for !doctype html or html, and wraps them in html if these are not found. (Seb, does this cover the problems you experienced?) I think there is a more general problem of making Zope content-neutral, but that is a proposal for another time. Regards, Noel Duffy. Cheers, Noel. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] standard_error_message and displaying non-html content.
Steve Alexander writes: seb bacon wrote: I don't believe there is a clean way. I've changed the source not to display its own html at all. It's not nice, but I suppose that's the benefit of OSS. Is there a FishBowl proposal on remedying this? If not, there should be one. Perhaps someone who has this itch to scratch can get the ball rolling? First, thanks for the quick response. Secondly, I would be willing to start this process, but my knowledge of Zope internals is patchy at best, so I might not be the best person for this. Still, if no-one else wants to, I will give it a go. Just to clarify, I am only concerned at present with the code in HTTPResponse that, in the case of an exception, scans for !doctype html or html, and wraps them in html if these are not found. (Seb, does this cover the problems you experienced?) I think there is a more general problem of making Zope content-neutral, but that is a proposal for another time. Regards, Noel Duffy. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
