[
https://issues.apache.org/jira/browse/BOOKKEEPER-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402706#comment-13402706
]
Sijie Guo commented on BOOKKEEPER-309:
--------------------------------------
{quote}
But JMS assumes some basic functionality to be provided by every messaging
system : the reason for changes to hedwig protocol was necessitated due to lack
of these in hedwig : a) lack of support for metadata for messages, b) returning
published message's id.
The list is actually much longer, but as I mentioned elsewhere, we simulate a
lot of the changes within provider (some of them poorly as a kludge) to
minimize changes to hedwig and protocol : which was a priotity one requirement.
{quote}
b) is a dependency for you to implement JMS provider. so my suggestion when
reviewing all sub tasks is you should put all changes related to b) together in
a separated jira like 'support returning published message id'. Not spread it
over several jiras mixed with other features.
besides that, I found you change 'consume' behavior. so 'changing consume
behavior' would be another jira to handle it, not mix it with other jiras.
so for BOOKKEEPER-308, you have several tasks need to be done:
1. Support returning published message id
2. Changing consume behavior
3. Add metadata support in Message for JMS
4. JMS provider implementation
1, 2, 3 are independent, while 4 depends on 1, 2, 3. How about changing sub
tasks as above? so we don't need to spread discussion over different jiras,
make each jira focus on one feature.
{quote}
In my opinion, relying on raw bytes to convey semantics for metadata will make
interoperable implementations impossible as features evolve, and/or as more
language bindings are added; so when taking a call, please take that into
consideration.
{quote}
I don't think there is language binding issue for a generic key/bytes header,
because you are using protobuf. You could create a kind of message called
JMSValue.
{code}
message JMSValue {
enum Type {
BOOLEAN = 1;
BYTE = 2;
SHORT = 3;
INT = 4;
LONG = 5;
FLOAT = 6;
DOUBLE = 7;
STRING = 8;
};
required Type type = 1;
optional bool booleanValue = 2;
optional sint32 byteValue = 3;
...
}
{code}
What I concerned most is that mixing hedwig protocol with jms protocol together
is not a good idea. It introduced overhead for those native hedwig client
users. I think it would not be difficult to decouple them.
{code}
message JMSMessage {
+ repeated Key2Boolean booleanMetadata = 4;
+ repeated Key2Byte byteMetadata = 5;
+ repeated Key2Short shortMetadata = 6;
+ repeated Key2Integer integerMetadata = 7;
+ repeated Key2Long longMetadata = 8;
+ repeated Key2Float floatMetadata = 9;
+ repeated Key2Double doubleMetadata = 10;
+ repeated Key2String stringMetadata = 11;
+ optional JmsBodyType jmsBodyType = 12;
+}
+
+enum JmsBodyType {
+ STREAM = 0;
+ MAP = 1;
+ TEXT = 2;
+ OBJECT = 3;
+ BYTES = 4;
+ // no payload, only message.
+ MESSAGE = 5;
+}
+
+message Key2Boolean {
+ required string key = 1;
+ required bool value = 2;
+}
+
+message Key2Byte {
+ required string key = 1;
+ // since protobuffer does not support sint8, we use sint32. We need this
explicitly to differentiate between
+ // byte and int headers.
+ required sint32 value = 2;
+}
+
+message Key2Short {
+ required string key = 1;
+ // since protobuffer does not support sint16, we use sint32. We need this
explicitly to differentiate between
+ // byte and int headers.
+ required sint32 value = 2;
+}
+
+message Key2Integer {
+ required string key = 1;
+ required sint32 value = 2;
+}
+
+message Key2Long {
+ required string key = 1;
+ required sint64 value = 2;
+}
+
+message Key2Float {
+ required string key = 1;
+ required float value = 2;
+}
+
+message Key2Double {
+ required string key = 1;
+ required double value = 2;
+}
+
+message Key2String {
+ required string key = 1;
+ required string value = 2;
}
{code}
you could have a JMSMessage protobuf definition to carry all jms related
things, and put it in JMS proto file which is just used in hedwig-jms-client.
And a JMS
> 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
>
>
> 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
