[ 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