FLUID-5333: Create support for "abortable events" in the framework, to deal with cases where the holding component is destroyed

Metadata

Source
FLUID-5333
Type
Bug
Priority
Major
Status
Closed
Resolution
Fixed
Assignee
Antranig Basman
Reporter
Antranig Basman
Created
2014-04-28T02:06:07.563-0400
Updated
2015-10-08T14:16:17.679-0400
Versions
N/A
Fixed Versions
  1. 1.9
Component
  1. Framework
  2. IoC System

Description

This requirement was raised by FLUID-5332. A difficult form of race condition can emerge where a component holding an event or a listener is destroyed as a result of servicing one of the listeners. A clean solution to this issue would involve being able to formally abort the processing of a listener queue when the component holding its event is destroyed partway through the process. This is similar to the "preventable events" system that we still retain in outline, but is signalled by collateral action around the component tree rather than specific knowledge held within a listener as signalled by its return value.

This kind of race should not really occur in practice, but is unfortunately at a much greater risk as a result of our current renderer implementation which causes large-scale destruction of segments of the component trees that it manages whenever re-rendering occurs.

This implementation will interact well with our upcoming asynchronous models for communicating failure, when these are configured to do so by propagating a "ball of fire" up the component tree destroying components. In this case it is highly appropriate to abort any further listener notifications that are in progress when the error occurs - this is consistent with the standard semantics for "failed promises", not to say the analogous monadic model.

Comments

  • Antranig Basman commented 2014-08-21T18:47:34.953-0400

    Merged into master at revision f5403d5027923475e0c4314005f6723d2e732759

  • Justin Obara commented 2015-06-26T09:51:32.508-0400

    Reopening to change the fix version to 1.9