[
https://issues.apache.org/jira/browse/BOOKKEEPER-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400685#comment-13400685
]
Mridul Muralidharan commented on BOOKKEEPER-309:
------------------------------------------------
{quote} I would prefer not to put anything JMS specific into the hedwig
protocol. If JMS is running on top, of hedwig, it should run on top. There
shouldn't be cross contamination between the protocols. I think this is quite
easy though.
{quote}
There were two (somewhat) conflicting requirements :
a) to be able to interoperate seemlessly (as much as possible) with existing
hedwig clients - that is, mixing producers and consumers between "native"
hedwig api and jms provider clients.
b) to be able to use jms specific features without breaking backward
compatibility - so that producer or consumer which is using jms specific idioms
can continue to work without breaking other clients.
Given this, the options to support message metadata were :
1) make it inline as part of the message itself : this will break all existing
clients since they will not be able to parse the content of the message.
2) Extend protocol to add support for metadata : so that only clients which
need to query, would do so, while the rest can continue to ignore the
additional metadata fields.
My understanding of protobuffer is very naive at best, but I was given to
understand that this sort of evolution was supported : please do correct me if
I am wrong.
Given this, I choose the approach (2).
{quote}
JmsBodyType is an enum. It can be very easily implemented as a byte in the
metadata, and a byte->enum mapping used on the jms client.
{quote}
You are right, this is a JMS specific metadata change - something which slipped
my mind when I was making the changes.
The only constraint is, we have to ensure it is a global mapping - so that
different interpretations dont arise : which is why I used an enum to
document/enforce it in protocol itself.
If there is another registry in client api (or elsewhere) where this can be
specified, it will probably be a more extensible approach (to reduce protocol
changes).
{quote}
I think there should be only 1 metadata in Message, which is a repeated of a
generic 'KeyValue' type.
...
In fact, I'm inclined to think there should only be a 'bytes' value type, and
leave it up to the application to decode it correctly. Sijie was talking about
adding metadata recently, so we should also discuss this with him.
{quote}
I like the generic KeyValue metadata - it was something I did not pursue in
detail since I was not sure what all value types will be required.
In JMS, it is restricted to primitives, but in hedwig will it include other
data structures, etc ?
I was hoping the review process will thrash out a better metadata format based
on the collective experience in use of hedwig - just that it be something which
will allow the basic requirements to be supported (in addition to others) !
About leaving it as 'bytes' - I would prefer if we had the value cleanly
specified : conflicting interpretations between clients can be avoided -
ideally, if there was some sort of union support in protobuf, all the more the
better; else, the proposal above sounds fine (with extensions as required).
{quote}
body cannot be changed from required to optional unfortunately, as this is a BC
break. However, we can have a 'bodyEmpty' boolean metadata value, which the
client can interpret to mean the same thing.
{quote}
IIRC you had mentioned this before and it slipped my mind, my apologies !
I will add an optional flag and revert changes to make body optional. In case
body is missing, I will set it to an new byte[0] - hope that would not break
things ...
{quote}
1 final proceedure point. When you do a git diff, use (--no-prefix). It means
that a patch will apply with patch -p0, which is a convention we prefer (not
that it's particularly better than -p1, but its like driving on one side of the
road).
{quote}
Will do !
Do you want me to regenerate all patches attached to the issue(s) ?
> 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
