[
https://issues.apache.org/jira/browse/BOOKKEEPER-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276374#comment-13276374
]
Sijie Guo commented on BOOKKEEPER-261:
--------------------------------------
@Aniruddha, thanks for explanation.
the case is OK, but just be curious that it seems that all the clients connect
to a same domain name and which host the client would connect is determined
according to some kind of geo-location. If so, there is a chance that a
subscribe is moved from one region to another region. You might encounter
inconsistent subscription state problem during subscriber movement as described
in BOOKKEEPER-147.
If it worths discovering the region info, I prefer 2) solution you proposed.
Because hub server has the information which region it belongs to, you just
need to add the region info at the response of publish/subscribe. And I would
suggest it could be done more flexible by adding a meta block (a key/value map)
in the response of publish/subscribe like http response header. 1) region info
could be respond as the value of meta key 'Region' 2) it might be easy for us
to add more in future if necessary.
> Let a hedwig-client discover the region of the hedwig-server cluster it is
> connected to
> ---------------------------------------------------------------------------------------
>
> Key: BOOKKEEPER-261
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-261
> Project: Bookkeeper
> Issue Type: Improvement
> Components: hedwig-client
> Reporter: Aniruddha
> Priority: Minor
>
> Currently, the client-server protocol doesn't let a Hedwig client discover
> the region that it is a part of. There are a couple of approaches that I
> could think of to do this - 1) The client publishes and subscribes to a
> randomly generated topic-name. It can then set it's region to the srcRegion
> of the received message. 2) Have a discovery operation akin to the
> publish/subscribe operations and let the server respond to this with
> information about itself (region name and any other information it might want
> to pass on to the client). I personally prefer (2). I could produce a patch
> if the approach looks good.
--
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
