What is the lapsed listener problem?
The lapsed listener problem is one of the primary causes of leaks in .NET applications. It occurs when a subscriber (or ‘listener’) signs up for a publisher’s event, but fails to unsubscribe. The failure to unsubscribe means that the publisher maintains a reference to the subscriber as long as the publisher is alive. For some publishers, this may be the duration of the application. This situation causes two problems. The obvious problem is the leakage of the subscriber object. The other problem is the performance degredation due to the publisher sending redundant notifications to ‘zombie’ subscribers. There are at least a couple of solutions to the problem.
The lapsed listener problem is one of the primary causes of leaks in .NET applications. It occurs when a subscriber (or ‘listener’) signs up for a publisher’s event, but fails to unsubscribe. The failure to unsubscribe means that the publisher maintains a reference to the subscriber as long as the publisher is alive. For some publishers, this may be the duration of the application. This situation causes two problems. The obvious problem is the leakage of the subscriber object. The other problem is the performance degredation due to the publisher sending redundant notifications to ‘zombie’ subscribers. There are at least a couple of solutions to the problem. The simplest is to make sure the subscriber is unsubscribed from the publisher, typically by adding an Unsubscribe() method to the subscriber. Another solution, documented here by Shawn Van Ness, is to change the publisher to use weak references in its subscriber list.
The lapsed listener problem is one of the primary causes of leaks in .NET applications. It occurs when a subscriber (or ‘listener’) signs up for a publisher’s event, but fails to unsubscribe. The failure to unsubscribe means that the publisher maintains a reference to the subscriber as long as the publisher is alive. For some publishers, this may be the duration of the application. This situation causes two problems. The obvious problem is the leakage of the subscriber object. The other problem is the performance degredation due to the publisher sending redundant notifications to ‘zombie’ subscribers. There are at least a couple of solutions to the problem. The simplest is to make sure the subscriber is unsubscribed from the publisher, typically by adding an Unsubscribe() method to the subscriber. Another solution, documented here by Shawn Van Ness, is to change the publisher to use weak references in its subscriber list.
