High Throughput Flex: A Strategy for Handling Multiple Messages in a Single Frame
I was asked the other day how I would handle a high throughput of data in a Flex application. A good example could be a monitoring dashboard that uses the Consumer class to subscribe to messages that may be sent to clients many times in a single Flex frame.
The immediate answer may be to simply handle the Consumer's message event and set your client properties each time that event is dispatched. However, the issue with this strategy is that the event could be dispatched multiple times in a single frame and if your code uses commitProperties() to coordinate property changes on your components, all but the last message in a frame could be lost.
My solution is that components listening to the Consumer's message event dispatch add each event to a buffer (implemented as a Vector) before invoking invalidateProperties(). In the commitProperties() method, my code loops over the buffer and aggregates the data received.
I did a quick and dirty proof of concept which you can see here. This version uses Parsley, subscribes to the Tour De Flex connection feed and works like this:
- I created a Parsley version of the regular Flex Consumer. Rather than dispatching a Flash event, it dispatches a Parsley message.
- The presentation model, HighFrequencyConsumerPM, responds to that message and dispatches a regular Flash event with the same payload. This is done to help make my view classes framework agnostic, but is probably overkill in this little demo.
- My view class, ConnectionSummaryView is injected with HighFrequencyConsumerPM and listens for that event. It's that event handler that starts populating the buffer and invokes invalidateProperties().
- On ConnectionSummaryView's commitProperties(), the buffer is passed to another little presentation model that handles the aggregation of the messages and populates a bindable array collection that is used to populate a pie chart and summary view.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)