summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorNick Hudson <nick.hudson@isode.com>2015-07-28 10:20:31 (GMT)
committerNick Hudson <nick.hudson@isode.com>2015-07-29 14:54:53 (GMT)
commit7c1715ada34e6ebfd82a22f67a7346f85d4a3158 (patch)
tree773c1145eefa80ad4cd5a9ecbb52328929d1b4f5 /Documentation
parente0c9b2b7b40743ec4f5f1dd5bc1eaf0e815ed72e (diff)
downloadstroke-7c1715ada34e6ebfd82a22f67a7346f85d4a3158.zip
stroke-7c1715ada34e6ebfd82a22f67a7346f85d4a3158.tar.bz2
Reinstate "disconnect()" method for MUC class
A recent change (9ead0fdcca595df9dc3f4143122776b398dbe405) made MUC an abstract class, and moved all functionality into MUCImpl (to correspond with Swiften). The "disconnect()" method was moved to MUCImpl, which means that any existing application which used it would break. The disconnect() method is required in java (although it's not in Swiften) because it provides a way to disconnect signals that are connected in the MUC constructor (or MUCImpl constructor now). While the signals are connected, the MUC object will not be eligible to be garbage collected, and this can lead to growing memory usage for an application which creates lots of MUC objects for a given connection. Adding a call to "disconnect()" in the finalizer for the MUC would not be effective because the finalizer only gets called when the MUC is gc'd, and the MUC can't be gc'd until the disconnect() has happened. Test-information: Unit tests pass. Before this change, an application calling "MUC.disconnect()" fails to compile. After this change, the application compiles. Tested an app that creates lots of MUC objects, and checked, using the debugger, to see if the objects were being garbage collected when the application dropped its reference to the objects. When not calling "disconnect()", the MUC objects are not garbage collected until the owning StanzaChannel is closed. When a call to "disconnect()" was added, the MUC objects are garbage collected soon after the application finishes using them, even though the StanzaChannel is still in use. Change-Id: Icd6c354e34d2124c292ae5d44bc47725a6e73df5
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions