[
https://issues.apache.org/jira/browse/BOOKKEEPER-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402907#comment-13402907
]
Mridul Muralidharan commented on BOOKKEEPER-309:
------------------------------------------------
{quote}
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}
To clarify the list above, primarily : changes to 1 are spread between client,
server and protocol; changes for 2 is local to client; changes to 3 is local to
protocol; ofcourse 4 depends on all of the above implicitly for functionality.
Unfortunately, changes to client for 1 and 2 are interdependent (getCallback(),
etc) - 2 was not an expected change, had to be introduced due to failing tests
much later in the implementation and so depends on 1 implicitly (I did not know
consume() was async inspite of name !).
I think more time and effort is being expended to clarify why things are
interdependent; I might be better off simply splitting the patches if reviewing
them is causing problems :-) I will get to it later this week when I have some
time.
Regarding having a bytes header type -
The questions would be :
* Is there a need for generic metadata in hedwig ? If yes, then we have to do
it such that the metadata types supported in JMS are part of it.
* What sort of interoperability is being considered between various producers
and consumers - our assumption was there must be as much as possible (except
for domain specific things like Serializable message type, etc).
Note that metadata in JMS is primarily required for two reasons :
* headers added by JMS provider based on message producer's & consumer's
expectation from JMS (filtering, type info, simulating expiration, etc).
* headers added by message producer's explicitly for consumption at the
client's (filtering, user specific, etc).
Note that one or more producer(s) or the consumser(s) need not necessarily be
using JMS : which is the reason for trying to keep metadata in protocol itself
to allow for interoperability.
If this usecase does not make sense, then yes, we can have a JMS provider
specific private interpretation of a bytes header - with impact on future
evolution and interoperability.
> 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
