> * in MultiVersionProtocolEngine you set _delegate to null, same with > _protocolEngine in MINANetworkDriver, and the Mina IoSession attachment is > also set to null. Which of these was *actually* preventing the GC from > reclaiming memory? If we know that, then we can remove only that reference. > This many seems like overkill if the session can be closed properly. > * in Connection, setState(CLOSED) is functionally equivalent to the two > lines you replace it with, since the monitor on lock is held already. > * calling _connection.onOpen(null) from the closed method in > ProtocolEngine_0_10 seems odd. It sets the _onOpenTask of ServerConnection > to null, which you could do in setState(CLOSED) of ServerConnection (see > previous item) instead? >
Hi Andrew, Sorry for the late reply. Well I was using a fork of fairly old 0.9 trunk. The patch was supposed to fix two issues that caused memory leaks. 1. Setting varouse references to null (yeah it looks little odd :-)) in differnet places was required to remove circular references that prevented ProtocolEngine_0_10 objects from getting GC'ed. 2. Replacing setState(CLOSED) with the particular peice of code in Connection was required to fix a synchronization issue that prevented bulk of the ProtocolEngine_0_10 instances getting removed from the _typeMap in ConfigStore. Hence a memory leak. Anyway I do not notice those issues in the latest trunk. But still I see ServerConnection instances lying without getting GC'ed. I doubt its due to a circular ref issue too. Let me check on that and get back to you. Also I see MINANetworkDriver.sessionClosed not getting called too. Thanks, Danushka
