#485: Topic-based pub/sub for IResourceChangeListener
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: nobody
Type: | Status: new
enhancement | Milestone:
Priority: major | Version:
Component: trac core | Keywords: gsoc gsoc2013submitted
Resolution: | IResourceChangeListener performance
-------------------------+-------------------------------------------------
Changes (by jdreimann):
* keywords: gsoc IResourceChangeListener performance => gsoc
gsoc2013submitted IResourceChangeListener performance
Old description:
> Resource listeners often will watch events for a limited , well-known set
> of resource realms (e.g. `ticket` + `attachment` ) .
>
> The current dispatching strategy (i.e. `match_resource`) is mostly
> [http://en.wikipedia.org/wiki/Publish–subscribe_pattern#Message_filtering
> content based] . It behaves in `O(r * l)` order of magnitude . This might
> lead to a lot of extra (unnecessary) overhead .
>
> A performance improvement could be to allow listeners to register to
> dedicated realm channels (i.e.
> [http://en.wikipedia.org/wiki/Publish–subscribe_pattern#Message_filtering
> topic-based filtering]) , thus turning the dispatch algorithm into `O(l)`
> , at least when it is a ok to do so ;)
>
> PS: We shall not loose the current content-based filtering capabilities ,
> so in advance I advocated using a hybrid strategy .
New description:
Resource listeners often will watch events for a limited, well-known set
of resource realms (e.g. `ticket` + `attachment` ).
The current dispatching strategy (i.e. `match_resource`) is mostly
[http://en.wikipedia.org/wiki/Publish–subscribe_pattern#Message_filtering
content based]. It behaves in `O(r * l)` order of magnitude. This might
lead to a lot of extra (unnecessary) overhead.
A performance improvement could be to allow listeners to register to
dedicated realm channels (i.e.
[http://en.wikipedia.org/wiki/Publish–subscribe_pattern#Message_filtering
topic-based filtering]), thus turning the dispatch algorithm into `O(l)` ,
at least when it is a ok to do so ;)
PS: We shall not loose the current content-based filtering capabilities ,
so in advance I advocated using a hybrid strategy.
--
Comment:
[https://issues.apache.org/jira/browse/COMDEV-95 Relevant GSoC submission]
in COMDEV Jira project.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/485#comment:2>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
