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