--- On Thu, 24/1/13, Sven Van Caekenberghe <[email protected]> wrote:
> From: Sven Van Caekenberghe <[email protected]> > Subject: Re: [Pharo-users] Memory Leak with Zodiac? > To: "A friendly place where any question about pharo is welcome" > <[email protected]> > Date: Thursday, 24 January, 2013, 10:41 > Hi Chris, > > On 24 Jan 2013, at 11:02, CHRIS BAILEY <[email protected]> > wrote: > > > I'm having a little trouble with a possible memory leak > with Zodiac. I'm running Pharo 1.4 Summer on Centos > 6.3/Fedora 18 for deploy/dev. The plugin is using > libssl.so.0.9.8, and I also seem to have another version > kicking about which uses libssl.so.6 and am not really sure > where I got that from. It may be an older one from the > http://code.google.com/p/squeakssl/ site. Both have the > same effect, i.e. when running 100 timesRepeat: [ ZnClient > new url: 'https://www.google.com'; get ] VIRT and RES memory both > go up about 70mb, but just using http doesn't accumulate > any. I tried it in Pharo 2.0 which was the same, but the new > NBCog doesn't include the libSqueaKSSL.so so I was only > copying it over. > > > > Has anyone used it successfully in the same > environment? I'll try it on Ubuntu when I get a chance. > > > > Thanks > > Chris > > Thanks for testing this ;-) > > Note that although ZnClient is most often used to do just > one request, it was also designed to be reused to do > multiple request to the same host:port. Even when not taking > care of resource cleanup, for casual use #close to the > socket will eventually be sent where necessary due to > finalization. Helping a bit makes for better performance. > > Either one of the following would be better: > > 100 timesRepeat: [ ZnClient new beOneShot; get: 'https://www.google.com' ]. > > 100 timesRepeat: [ ZnClient new get: 'https://www.google.com'; close ]. > > | client | > client := ZnClient new. > 100 timesRepeat: [ client get: 'https://www.google.com' ]. > client close. > > Now, Zodiac TLS/SSL Streams are more resource intensive: > they create ZdcPluginSSLSession instances which represent > native native data structures from the OS's SSL libraries. > These are only cleaned up when #destroy is sent, which is > one by ZdcSecureSocketStream>>#close. I didn't write > any explicit code to do this by finalization, so that > probably does not happen. Maybe we should experiment with > adding a #finalize to ZdcPluginSSLSession as an equivalent > to #destroy. > > It would be cool if you could test again. Hopefully memory > consumption improves. > > Hi Sven, thanks for the quick reply. Sorry, I didn't consider that when I reproduced it with the simplest example I could think of! I'm actually using it in the context of a single ZnClient being held open for an entire Seaside session which talks to an external web service. I therefore only send a close when the session ends. What solution would you recommend, as it is quite easy currently to run the image out of memory before the session gets unregistered. Thanks Chris
