Effective October 27, 2012, online and email support for FuseSource products will move to Red Hat support channels. For more information, please see the JIRA Migration to Red Hat FAQ.
As of October 27th, please open all new issues in the Red Hat Customer Portal .
Issue Details (XML | Word | Printable)

Key: MB-877
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Timothy Bish
Reporter: Torsten Mielke
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
FUSE Message Broker

Investigate into possible performance improvements when dispatching to durable topic subscribers with msg selectors

Created: 06/May/11 12:28 PM   Updated: 30/Sep/11 07:12 PM
Component/s: broker
Affects Version/s: 5.4.2-fuse-02-00
Fix Version/s: 5.5.1-fuse-01-06

Environment: durable topic subscribers with message selector


 Description  « Hide
When dispatching topic msgs to durable subscribers with msg selectors we always write the pending ack of each subscription to the index and persist the index, no matter whether the msg selector of the sub matches.
In usecases where there are many subscribers with msg selectors and the msg matches only a few subscribers, we persist acks that are not necessarily needed.
This place potentially unnecessary index writes and will affect the performance when dispatching to a lager number of subscribers.

We should investigate into improvements so that pending acks are not written for subscribers whose selectors anyway don't match the msg.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Timothy Bish added a comment - 22/Sep/11 09:21 PM - edited
After working through some of the test failures its become fairly obvious that applying the selector in KahaDB isn't really doable without some other major redesign work in the DB structure as you are left with insufficient information to properly recover durable subscriptions in many of the edge case scenarios. I worked through fixing that for many of the failing tests and ended up back to just about the same run times as reported previously and am still not confident that there aren't some other cases where we might fail to recover correctly. That being said I really can't recommend this approach at this time especially in the 5.6 release given the potential to introduce additional negative side effects.