On Tue, Nov 23, 2010 at 08:28:54AM -0500, Chris Lalancette wrote: > On 11/21/10 - 11:25:09PM, Pawel Krzesniak wrote: > > On 29.07.2010 20:32, Chris Lalancette wrote: > > >Ah, OK. So then the question becomes whether the problem is in the ruby > > >bindings not releasing the object in certain circumstances, or in rails > > >holding onto the object too long. Unfortunately I'm not really that familiar > > >with rails or passenger, so I'm not entirely sure how to figure out where the > > >problem is. > > > > > >I'll see if I can do a bit of testing and look at object lifetimes from the > > >point-of-view of ruby-libvirt to try and eliminate that from the equation. > > > > following testcase confirms that problem is in bindings itself: > > OK, I see what the problem is. I'm not entirely sure if it is actually a > problem in the bindings, but the behavior is a bit surprising in a > garbage-collected language. See below. > > > ree-1.8.7-2010.02 > require 'libvirt' > > => true > > ree-1.8.7-2010.02 > puts `netstat -na|grep -v LISTENING |grep -c > > libvirt-sock` > > 0 > > => nil > > ree-1.8.7-2010.02 > c = Libvirt::open 'qemu:///system' > > => #<Libvirt::Connect:0x265b718> > > ree-1.8.7-2010.02 > puts `netstat -na|grep -v LISTENING |grep -c > > libvirt-sock` > > 1 > > After this point, we have a single connection. > > > => nil > > ree-1.8.7-2010.02 > d = c.lookup_domain_by_name 'abc' > > => #<Libvirt::Domain:0x2705128> > > ree-1.8.7-2010.02 > puts `netstat -na|grep -v LISTENING |grep -c > > libvirt-sock` > > 1 > > Still the same connection. > > > => nil > > ree-1.8.7-2010.02 > c.close > > Here's where the problem is. Because you are doing c.close before cleaning up > the domain object, the libvirt library keeps a connection open. If you do > either: > > d = nil > GC.start > > or > > d.free > > before the c.close, then everything would be cleaned up correctly. > > In terms of making this automatically happen during connection closing, I'm > not entirely sure what we can (and should) do. I guess we could keep some sort > of list of objects that "depend" on this connection object, and then during > connection close free them all up. Does anyone know how the python bindings > handle this? They don't do anything. IMHO this is just expected behaviour. The domain objects reference the connections, so it is only natural that the connection remains around for as long as any domain (or other object) remains in scope. Daniel -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list