[
https://issues.apache.org/jira/browse/BOOKKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409585#comment-13409585
]
Sijie Guo commented on BOOKKEEPER-78:
-------------------------------------
yup. it might be different to change/add filter without restarting hub server.
but I don't think the main goal of server-side filtering is to resolve it.
the benefits of server-side filtering are:
1) reduce bandwidth delivering unnecessary messages to its subscribers.
2) separated the business logic from platform(hedwig) code.
server-side filter just gave chance to filter messages on server side.
> filterable metadata fields in Hedwig's message definition
> ---------------------------------------------------------
>
> Key: BOOKKEEPER-78
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-78
> Project: Bookkeeper
> Issue Type: New Feature
> Components: hedwig-client, hedwig-server
> Reporter: Matthieu Morel
>
> In order to efficiently implement filtering of Hedwig messages, Hedwig should
> be able to rely on metadata information. (i.e. without needing to deserialize
> the content of the message)
> Filtering could use a subset of SQL (like in the JMS spec), leading to
> queries such as :
> "header1 like 'a' AND header2 IS NOT NULL"
> For that purpose, I propose to add customizable metadata to the definition of
> Hedwig messages, as header fields.
> Metadata must be customizable because it may be arbitrary. We should provide
> "map-like" containers according to the type of the metadata field. Metadata
> fields would be accessed by name.
> There are predefined headers for JMS that could be added as metadata fields
> such as : destination (~topic), delivery mode (persistent or not),
> expiration, priority, timestamp, correlation id (link to other message),
> reply to, type and redelivered. I think only a subset of these should be
> predefined headers, if any.
> Adding metadata fields to Hedwig messages implies modifying the message
> definition, which does not break backward compatibility when those fields are
> added as optional in the protocol buffer definition.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
