[IronPython] IronPython with CherryPy through WSGI Memory issue

[Can Gencer]

I do not have the DynamicStackFrame problem, though I do not have
Frames enabled.

I 've managed to solve all the memory leak issues now (hopefully), the
last one was caused by the session handler in CherryPy. The cleanup
thread was not being started due to some reason. It seems that you
have to call the cherrypy.session object at least once to start up the
cleanup thread.

I use the wsgi.py found in FePy like this (if anyone is interested in
trying it out..)

        public void ProcessRequest(HttpContext context)
        {
            var func = GetWsgiFunction();
            func.__code__.Target.DynamicInvoke(func, context,
GetApplicationCallable(_engine), context.ApplicationPath);

        }

        private PythonFunction GetWsgiFunction()
        {
            if (_wsgiFunction = null)
            {
                ScriptScope scope = _engine.CreateScope();
                _engine.CreateScriptSourceFromString("import
wsgi").Execute(scope);
                _wsgiFunction =
scope.GetVariable<PythonModule>("wsgi").Get__dict__()["run_application"]
as PythonFunction;
            }
            return _wsgiMethod;
        }

GetApplicationCallable returns the application callable that is
created by CherryPy, that you get like this:

import cherrypy
application = cherrypy.tree.mount(root, "/")

On Fri, Apr 2, 2010 at 10:52 PM, Dino Viehland <dinov at microsoft.com> wrote:
>
>
> Jeff wrote:
>> I'm seeing a lot of objects with !gcroots that start with
>>
>> DOMAIN(005F5F48):HANDLE(Strong):161100:Root:02913dac(System.Threading.Thread)-
>> >
>> 0b93e034(System.Object[][])->
>> 0b93e048(System.Object[])->
>> 223edd34(System.Collections.Generic.List`1[[Microsoft.Scripting.Runtime.Dynami
>> cStackFrame,
>> Microsoft.Dynamic]])->
>> 223edd6c(System.Object[])->
>> 223edd4c(IronPython.Runtime.PythonDynamicStackFrame)->
>> 09441a48(IronPython.Runtime.FunctionCode)->
>> ...
>>
>> So it looks like it might be related to dynamic stack frames --
>> something that is in thread local storage and not getting cleaned up.
>
> Is this 2.6 or 2.6.1RC?  I wonder if this could be the finalizer thread.
> !do on the thread object should give you the managed thread ID which can be
> associated with the values in !threads.
>
> Anyway this is definitely the exception leak - which is now fixed for 2.7.  If
> This is happening on the finalizer thread then maybe there's somewhere else we
> need to clear this data for pre-2.7.
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>