[
https://issues.apache.org/jira/browse/BOOKKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403094#comment-13403094
]
Sijie Guo commented on BOOKKEEPER-78:
-------------------------------------
Let me summary the idea I described in BOOKKEEPER-309 as below.
In order not to mix JMS protocol with Hedwig protocol, which brings overhead to
those clients use original Hedwig client. I would suggested to add a generic
message header part in Hedwig Message definition.
The message header is described as below.
{code}
// common structure to store header or properties
message Map {
message Entry {
optional string key = 1;
optional bytes value = 2;
}
repeated Entry entries = 1;
}
// message header
message MessageHeader {
// user customized fields used for message filter
optional Map properties = 1;
// following are system properties in message header
optional string messageType = 2;
}
/*
* this is the structure that will be serialized
*/
message Message {
required bytes body = 1;
optional bytes srcRegion = 2;
optional MessageSeqId msgId = 3;
// message header
optional MessageHeader header = 4;
}
{code}
The MessageHeader part contains two part, one is a key/bytes list to store user
customized properties, the other part contains system properties used by Hedwig
(which could be extended in future).
User customized properties could be used by different applications to put its
application specific header in Hedwig Message Header, which might be used for
message filter. A generic bytes value for header part is to keep native hedwig
message simple. Those applications (protocols) sit on top of Hedwig should
serialize/deserialize the bytes data themselves.
For system properties part, there is only a 'messageType' property now.
Introducing 'messageType' in message header is tried to resolve
interoperability issue that Mridul. The applications (protocols) sit on top of
Hedwig could just detect 'messageType' to know what kind of type the message
is, without looking into message body or customized properties.
For JMS publisher, it could mark the message type as 'JMS' to identify the
message is generated by JMS publisher.
For JMS consumer, when it received a message marked as 'JMS', it knows how to
interpret the message. If it received a message without MessageHeader or
unknow message type, it could treat it as a native Hedwig message.
Keeping hedwig protocol independent from other application protocols, will make
things clearer and easier.
> 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
