Instrumenting the event publisher

[Kevin Day-7]

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
Index: source/ca/odell/glazedlists/event/SequenceDependenciesEventPublisher.java
===================================================================
RCS file: /cvs/glazedlists/source/ca/odell/glazedlists/event/SequenceDependenciesEventPublisher.java,v
retrieving revision 1.26
diff -u -r1.26 SequenceDependenciesEventPublisher.java
--- source/ca/odell/glazedlists/event/SequenceDependenciesEventPublisher.java 29 Mar 2009 14:17:16 -0000 1.26
+++ source/ca/odell/glazedlists/event/SequenceDependenciesEventPublisher.java 2 Jun 2009 23:11:09 -0000
@@ -27,7 +27,7 @@
  *
  * @author <a href="mailto:jesse@...">Jesse Wilson</a>
  */
-final class SequenceDependenciesEventPublisher implements ListEventPublisher, Serializable {
+final class SequenceDependenciesEventPublisher implements ListEventPublisher, Serializable, InstrumentedSequenceDependenciesEventPublisher {
 
     /** For versioning as a {@link Serializable} */
     private static final long serialVersionUID = -8228256898169043019L;
@@ -454,4 +454,13 @@
             return subject + separator + listener;
         }
     }
+    
+    public Instrumentation getInstrumentationSnapshot() {
+        List<SubjectAndListenerPair> pairs = new ArrayList<SubjectAndListenerPair>();
+        for (SubjectAndListener pair : subjectAndListeners) {
+            pairs.add(new SubjectAndListenerPair(pair.subject, pair.listener));
+        }
+        return new Instrumentation(pairs);
+    }
+
 }
\ No newline at end of file
Index: source/ca/odell/glazedlists/event/InstrumentedSequenceDependenciesEventPublisher.java
===================================================================
RCS file: source/ca/odell/glazedlists/event/InstrumentedSequenceDependenciesEventPublisher.java
diff -N source/ca/odell/glazedlists/event/InstrumentedSequenceDependenciesEventPublisher.java
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ source/ca/odell/glazedlists/event/InstrumentedSequenceDependenciesEventPublisher.java 1 Jan 1970 00:00:00 -0000
@@ -0,0 +1,38 @@
+/*
+ * Created on May 27, 2009
+ * (c) 2009 Trumpet, Inc.
+ *
+ */
+package ca.odell.glazedlists.event;
+
+import java.util.List;
+
+/**
+ * @author kevin
+ */
+public interface InstrumentedSequenceDependenciesEventPublisher {
+    public Instrumentation getInstrumentationSnapshot();
+    
+    
+    public class SubjectAndListenerPair{
+        public final Object subject;
+        public final Object listener;
+        
+        public SubjectAndListenerPair(Object subject, Object listener){
+            this.subject = subject;
+            this.listener = listener;
+        }
+    }
+    
+    public class Instrumentation{
+        private final List<SubjectAndListenerPair> subjectAndListeners;
+        
+        public Instrumentation(List<SubjectAndListenerPair> subjectAndListeners) {
+            this.subjectAndListeners = subjectAndListeners;
+        }
+        
+        public List<SubjectAndListenerPair> getSubjectAndListeners(){
+            return subjectAndListeners;
+        }
+    }
+}

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

[Endre Stølsvik-8]

Thanks, this was very helpful.

IIUC, the patch you propose is a nice kind of introspection into the publisher system. I personally find that very much in demand. As does a writeup like you provided. I would be pleased if something like this made it into any documentation place - preferably (also in) the JavaDoc.

If I could point the finger at anything, I'd love it if the concrete example was even more elaborated upon - maybe exemplify the failure modes of a too-simple system, and maybe have another example that maybe was somewhat more elaborate which pointed out the deferring of the firing of later-in-line lists.

Thanks,

Endre.

On Wed, Jun 3, 2009 at 01:44, Kevin Day <kevin@...> wrote:

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@...

[Kevin Day-7]

I actually started putting together a more complicated example in the email, but the ascii art became way too tough...

 

I almost think it would be better to provide source code that builds a complicated event pipeline, and use the instrumentation to display the subject/listener list at each phase of the building.  Anyone really interested in the details of how event ordering occurs could then step through the code in a debugger and see how things change as different list configurations occur.

 

The problem is that it takes a lot of work to put together a really complicated pipeline - the ones in our apps are so intrinsically tied to what we do that it would take me a good 20 or 30 hours to replicate it in a way that would be suitable for a tutorial.

 

 

I also wanted to mention:  The invariant in orderSubjectsAndListeners() is unbelievably clever.  Whoever thought that up (I think it was Jesse) gets my vote for elegant algorithm of the year award.  When I finally got my head around it, I felt like the sky parted and the sun shone down.  Very nice.

 

- K

 

----------------------- Original Message -----------------------

  

From: Endre Stølsvik

To: users@...

Cc: 

Date: Thu, 4 Jun 2009 00:11:46 +0200

Subject: Re: Instrumenting the event publisher

  

Thanks, this was very helpful.

IIUC, the patch you propose is a nice kind of introspection into the publisher system. I personally find that very much in demand. As does a writeup like you provided. I would be pleased if something like this made it into any documentation place - preferably (also in) the JavaDoc.

If I could point the finger at anything, I'd love it if the concrete example was even more elaborated upon - maybe exemplify the failure modes of a too-simple system, and maybe have another example that maybe was somewhat more elaborate which pointed out the deferring of the firing of later-in-line lists.

Thanks,

Endre.

On Wed, Jun 3, 2009 at 01:44, Kevin Day <kevin@...> wrote:

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@...

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

[Holger Brands]

I vote +0 on this proposal.
(I see obvious pros and cons and I don't want to get in the way if others find it useful)

Holger

> 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
>
> <hr>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

______________________________________________________
WEB.DE FreeDSL mit 6.000 Flatrate und Telefonanschluss
für 17,95 Euro/mtl.! http://produkte.web.de/go/02/


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

[James Lemieux]

One upon a time I got a free license from jgraph.com and actually wrote a small tool that would graph your pipeline for you. We had delusions of grandeur at the time that we could even overlay information over that graph like which transformations were taking the most time, or debugging information so you could watch the order of notification. I'm not even sure where that code is now...

Something like that would be a great teaching tool for GL too, to conceptually understand everything that is happening when you simply write myEventList.add(new Object());

At a minimum, I thank Kevin for clearly dedicating a lot of time to mining out his own answers and then sharing them with the group. If you ever care to write a really detailed description up, our wiki seems to be the perfect storage point for that writeup. ;-)

James

On Sun, Jun 7, 2009 at 1:21 PM, Holger Brands <hbrands@...> wrote:

I vote +0 on this proposal.
(I see obvious pros and cons and I don't want to get in the way if others find it useful)

Holger

> 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
>

> <hr>

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

______________________________________________________
WEB.DE FreeDSL mit 6.000 Flatrate und Telefonanschluss
für 17,95 Euro/mtl.! http://produkte.web.de/go/02/

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