[
https://issues.apache.org/jira/browse/BOOKKEEPER-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402158#comment-13402158
]
Mridul Muralidharan commented on BOOKKEEPER-309:
------------------------------------------------
>From what I understand, stomp is a wire level protocol - JMS is not, it is
>expected to expose existing messaging system functionality in a vendor neutral
>manner.
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.
Other than the subset above which is bare minimum and cant be simulated
(published message's id) or cant be done in an interoperable manner (metadata
for messages); rest are simulated in the provider (filtering, nolocal,
transactions, etc).
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. I would prefer if the metadata changes are generic enough that
it satisfies not just these subset of requirements, but also additional
metadata requirements that might exist to minimize future need to change
protocol.
Since I do not have enough visibility into this, I will leave it to the domain
experts.
> 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
