You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@bloodhound.apache.org by Apache Bloodhound <bl...@incubator.apache.org> on 2013/03/23 02:54:53 UTC
[Apache Bloodhound] #485: Topic-based pub/sub for
IResourceChangeListener
#485: Topic-based pub/sub for IResourceChangeListener
--------------------------+---------------
Reporter: olemis | Owner:
Type: enhancement | Status: new
Priority: major | Version:
Resolution: |
--------------------------+---------------
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)`
.
PS: We shall not loose the current content-based filtering capabilities ,
so in advance I advocated using a hybrid strategy .
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/485>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #485: Topic-based pub/sub for
IResourceChangeListener
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#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
Re: [Apache Bloodhound] #485: Topic-based pub/sub for
IResourceChangeListener
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#485: Topic-based pub/sub for IResourceChangeListener
-------------------------+-------------------------------------------------
Reporter: olemis | Owner: nobody
Type: | Status: new
enhancement | Milestone:
Priority: major | Version:
Component: trac core | Keywords: gsoc IResourceChangeListener
Resolution: | performance
-------------------------+-------------------------------------------------
Changes (by olemis):
* owner: => nobody
* keywords: => gsoc IResourceChangeListener performance
* component: => trac core
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)`
> .
>
> 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 .
--
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/485#comment:1>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker