2

I have a setup where there are two Cocoa processes, communicating with Distributed Objects (DO). The client is using garbage collection, the server is not.

It seems that the client hangs on to the distant objects outside of my direct references to them. This means that even after I don't have references to the objects, they hang around owned by NSDistantObjectTableEntry. Obviously they don't get deallocated on the server.

Only when the client is quit it lets go of all the distant objects. Breaking the connection manually would probably also work, but I don't want to do that while the client is running.

Is there a way to tell a GC'd DO client to let go of the distant objects that aren't referenced locally anymore?

  • Is the client an application or command-line tool? – Chris Hanson Oct 15 '08 at 04:43
  • Interestingly I found a very similar problem today only in my case neither side is using GC (I turned it off to ensure that it was not the cause of the bug). Checkout my question (http://stackoverflow.com/questions/2521514/memory-management-with-objective-c-distributed-objects-my-temporary-instances-li/2521526#2521526) and the example I posted there. Like you say, breaking the connection manually works but this doesn't seem right. So is there something we're fundamentally missing about the way DO works? – jkp Mar 26 '10 at 15:42

1 Answers1

1

There may be a retain cycle that spans the client and server - i.e. a client object is retaining a proxy of a server object, which is in turn retaining the proxy of the client's object.

That's a very simple example of a retain cycle, when more that two objects are involved it gets more complicated to diagnose.

See The Subtle Dangers Of Distributed Objects for example of other DO related gotchas.

Nick Dowell
  • 2,030
  • 17
  • 17