Re: Instrumenting the event publisher

I recently had need to dig inside the event publisher to see how dependencies were being made.  The attached patch provides a relatively unobtrusive way to allow outside folks access to the dependency information inside the publisher, and I thought it might be useful if anyone is having to debug event sequences.  It doesn't effect the public functional API of the publisher, so maybe adding it into the code base would be acceptable?

Here's how I use it:

       Instrumentation snapshot = ((InstrumentedSequenceDependenciesEventPublisher)(publisher)).getInstrumentationSnapshot();

I can then iterate over the publisher/listener list in the snapshot.  I created a little object registry where I could register an object and a meaningful name so make display of the event sequence list a bit more useful (the default toString() on EventList is a bit cumbersome for this type of debugging).


Having this at hand was incredibly helpful when figuring out the whole related listener system, etc...


For those of you who haven't done the spelunking into SequenceDependenciesEventPublisher, here's a brief description of how I think this all works:

The SequenceDependenciesEventPublisher maintains a list of subject/listener pairs.  A subject is an object that is listened to (this would be the 'publisher' in a simpler implementation, but publishing has been abstracted out, so 'subject' is a more appropriate term).

The list of subject/listener pairs is ordered in such a way that guarantees that if you fire an event to a given listener at it's last position in the list, all of it's dependencies will be met.

As a concrete example, consider the following list pipeline:

ListA ->                         -> SortedListA
            < FilteredList <
ListB ->                          -> SortedListB


In this case, the contents of ListB actually control the filter results.  So we have to declare ListA as a related listener to ListB


The publisher for this pipeline will contain the following subject/listener list (in the following, the list on the left is the subject, and the right is the listener):

Subject               Listener

ListA          -->   FilteredList
ListB          -->   FilteredList
FilteredList      -->   SortedListA
FilteredList      -->   SortedListB

If there is a change to ListB, the event publisher walks down the list and finds all rows with ListB as the subject (in this case, the second row).  It then fires the event into the listener (FilteredList).  During that event firing, FilteredList fires it's own event - but that gets put on a queue until all pending events have finished firing.  Now, the event for the FilteredList can be processed, so the publisher walks down the list, finds all listeners for FilteredList and fires the event.

This algorithm is quite efficient - all of the hard, expensive work occurs when ordering the subject/listener list in the first place (and that only happens when listeners or related subjects are being added and/or removed).

Anyway - hopefully this will shed a little bit of light on the magic of the event publisher.  If anyone wants to dig deeper, consider the invariant described in SequenceDependenciesEventPublisher.orderSubjectsAndListeners().  That invariant is the magic that orders the list correctly.  I understand the invariant mathematically, and why it works, but I'm having a bit of trouble putting it into English or pseudo code...

Cheerio,

- K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...