Hey Alex, I should probably have stated this better as memory is not always handled well. For example, the ext.db code keeps many copies of the data in various forms. This can cause rapid and unexpected memory blowups, and the result is something that appears similar to a memory leak. As Brian noted, this is partially caused by Python's handling of memory.
However, there are a number of scenarios where you get real memory leaks. For example there have recently been several posts / issues from people having issues with the blobstore leaking memory. Some of these are quite detailed and the repro code is very simple. If I'm not mistaken, in the past, we've observed this happening with heavy datastore use as well, though I don't have simple repro cases for those. Robert On Tue, Feb 21, 2012 at 16:13, alex <a...@cloudware.it> wrote: > The whole point of this topic was python27 runtime, multithreading and > concurrent requests. Your specific case, plus python 2.5, doesn't > necessarily means memory leaks in the runtime itself. I'd profile my code > that handles most frequently accessed URLs to start off. > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-appengine/-/ZyB9_mGBPDQJ. > > To post to this group, send email to google-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
