[
https://issues.apache.org/jira/browse/BOOKKEEPER-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401940#comment-13401940
]
Sijie Guo commented on BOOKKEEPER-310:
--------------------------------------
{code}
} else { // more than 10s
bucket = 3 * 9 + 1;
}
- ++latencyBuckets[bucket];
+ // This threw java.lang.ArrayIndexOutOfBoundsException: for me in
a test.
+ if (bucket < latencyBuckets.length) ++latencyBuckets[bucket];
}
{code}
could you provide more infos about this issue? I don't think it should over
bound.
{code}
b) Return the published message's seq-id in the response.
{code}
seems you separated the protocol change and code change in different jiras. it
is not easy to review. so a better idea to create a jira like 'support
returning seq-id for publish requests' to include the protocol change, code
change and test cases together.
{code}
@@ -138,6 +201,9 @@ message PubSubResponse{
optional Message message = 5;
optional bytes topic = 6;
optional bytes subscriberId = 7;
+
+ // If the request was a publish request, this was the message Id of the
published message.
+ optional MessageSeqId publishedMsgId = 8;
}
{code}
It would be better to have a generic field called 'respBody' to adapt different
response body for different requests, otherwise we have to put lots of optional
fields in PubSubResponse for different requests. since PubSubResponse is also
used for Message delivery, it should not put too many fields in future changes.
so a better solution is
{code}
message PublishResponse {
required MessageSeqId publishedMsgId = 2;
}
message ResponseBody {
optional PublishResponse pubResponse = 2;
}
message PubSubResponse{
required ProtocolVersion protocolVersion = 1;
required StatusCode statusCode = 2;
required uint64 txnId = 3;
optional string statusMsg = 4;
//in case of a status code of NOT_RESPONSIBLE_FOR_TOPIC, the status
//message will contain the name of the host actually responsible
//for the topic
//the following fields are sent in delivered messages
optional Message message = 5;
optional bytes topic = 6;
optional bytes subscriberId = 7;
// the following fields are sent by other requests
optional ResponseBody respBody = 8;
}
{code}
so if we want to add response for other type requests, we could add optional
fields in ResponseBody. Actually it is what we did in a message filter feature
we are working on, to return subscription preferences in subscribe response.
> Changes in hedwig server to support JMS spec
> --------------------------------------------
>
> Key: BOOKKEEPER-310
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-310
> Project: Bookkeeper
> Issue Type: Sub-task
> Reporter: Mridul Muralidharan
> Attachments: hedwig-server.patch
>
>
> The primary changes are :
> a) Support modified protocol changes (optional body).
> b) Return the published message's seq-id in the response.
> c) Minor bugfix to Array indexing in bucket which was triggered in a testcase.
--
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
