SOAP::Lite leaking memory
Gareth Harper
gareth at migcan.com
Thu Mar 15 12:02:27 GMT 2007
Jonathan Stowe wrote:
>"going out of scope" is not necessarily going to cause everything to go
>away as SOAP::Lite dynamically creates methods in a variety of
>namespaces (I'm not going to check right now as the code makes me
>uneasy) and it is possible that it is closing over some of the lexical
>variables.
>
>
>
It's going out of scope as far as any of the code I have written works
(there's nothing clever in my code, it's a very basic class), however
I'm fairly certain that SOAP::Lite is creating some things and caching them.
>If you are using the "autoloaded" interface (i.e.
>$soap->YourMethod(@args) ) you might want to try the explicit call (i.e.
>$soap->call('MyMethod', @args) ) as that is possibly going to fiddle
>with the symbol table less.
>
>
>
I'll check that out, but from what I was seeing in the results from
Devel::Leak a lot of the information in those variables is the actual
XML back and forth between my client and the server. I've just
installed Devel::LeakTrace::Fast which supposedly lets me know which
line is allocating the variables. if it's in the constructor I might
have to just bite the bullet and use a global. I'd rather not have to
manually remove references to various objects internal to SOAP::Lite.
>You might also want to test this with just re-using the single
>SOAP::Lite object as I seem to recall that most of the horrible stuff
>happens in the constructor.
>
>
I can try this, though I'd rather not, as the module I'm writing is to
be dynamically loaded as required by one of our systems (effectively
it's a turing engine, but it's a little more complex and specialised
than that) as required. Making the module when loaded keep a global
around with a SOAP object in it is feasable but undesireable. I did
troll through the SOAP::Lite documentation in the hope of a "don't cache
objects" option just in case but that didn't appear. For testing
purposes I'll create a global and see if that prevents the memory leaks,
if it does at least it gives me a somewhat nicer alternative than
forking off a process every time this function gets called.
More information about the london.pm
mailing list