incubator-bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <bloodhound-...@incubator.apache.org>
Subject Re: [Apache Bloodhound] #485: Topic-based pub/sub for IResourceChangeListener
Date Tue, 26 Mar 2013 18:12:38 GMT
#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

Mime
View raw message