[
https://issues.apache.org/jira/browse/BOOKKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403896#comment-13403896
]
Matthieu Morel commented on BOOKKEEPER-78:
------------------------------------------
The goal of this ticket is to suggest a convenient way to filter messages.
Since JMS clearly defines such a feature, the idea was to reuse it (abstracted
from JMS) so that it could be applied to any kind of Hedwig message. And of
course, the filtering could/should be performed efficiently directly on the
broker.
I have the impression that Sije's proposal would add very generic metadata, and
let the filtering logic to be implemented by protocols/applications that "sit
on top of Hedwig". I have a few questions:
* Does that mean filtering is only in protocol-specific clients, or would there
be a filtering mechanism in the broker itself?
* By default, would there be filtering capabilities in Hedwig?
* Don't you want to have typed SQL-like filtering capabilities by default?
> 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
