[
https://issues.apache.org/jira/browse/BOOKKEEPER-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409258#comment-13409258
]
Sijie Guo commented on BOOKKEEPER-309:
--------------------------------------
@Mridul, thanks for explanation. comments are as blow:
{quote}
Without type information, any attempts to filtering will be broken.
More specifically, in case of JMS, there are strict rules in terms of
conversion between types - which cant be inferred without the type.
{quote}
for resolving jms type, there are two kind of solutions:
1) first is to encode jms message in the body of hedwig message. and mark the
hedwig message type as 'JMS' in messageType field in MessageHeader.
2) second is to leverage hedwig generic properties field in MessageHeader. you
could have JmsValue type in jms.protocol in hedwig-jms-client package as below:
{code}
+message JmsValue {
+ enum ValueType {
+ BOOLEAN = 1;
+ BYTE = 2;
+ SHORT = 3;
+ INT = 4;
+ LONG = 5;
+ FLOAT = 6;
+ DOUBLE = 7;
+ STRING = 8;
+ // raw bytes. (custom correlation id, for example, uses this : though
we dont support it right now).
+ BYTES = 9;
+ };
+
+ required ValueType type = 1;
+
+ optional bool booleanValue = 3;
+ optional sint32 byteValue = 4;
+ optional sint32 shortValue = 5;
+ optional sint32 intValue = 6;
+ optional sint64 longValue = 7;
+ optional float floatValue = 8;
+ optional double doubleValue = 9;
+ optional string stringValue = 10;
}
{code}
you could serialize JmsValue as a byte array and put in hedwig's message header
and you also could deserialize bytes to a JmsValue.
both solutions could let jms protocol in its package, so its changes just take
effects on hedwig-client-jms module not other modules.
{quote}
Having said that, the individual diff's currently in the jira's loosely follow
this already - (2) and (3) are mostly split along consume and publish whereever
possible, but are not independently applicable due to hedwig code level overlap.
{quote}
yes. the new patches are quite loosely coupled. I had some comments on them on
BOOKKEEPER-310, BOOKKEEPER-311.
separating the patches by features is not only easy for reviewing but also for
discussion when there are different opinions. as my comments on message header
and consume request (in BOOKKEEPER-311), there are still different opinions so
it would better to have separated jiras for discussion.
for supporting returning message seq id, we both agreed on how to resolve it
and you had did a great work on it, so I think it could go to be committed
first and I created a sub-task BOOKKEEPER-331 for it. It might be great to put
the related changes from BOOKKEEPER-309, BOOKKEEPER-310, BOOKKEEPER-311
together when you update the patch.
> Protocol changes in hedwig to support JMS spec
> ----------------------------------------------
>
> Key: BOOKKEEPER-309
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-309
> Project: Bookkeeper
> Issue Type: Sub-task
> Reporter: Mridul Muralidharan
> Attachments: hedwig-protocol.patch, hedwig-protocol.patch.1
>
>
> JMS spec compliance requires three changes to the protocol.
> a) Support for message properties.
> b) Make body optional (message contains only properties).
> c) Return the published message's seq-id in the response.
--
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
