[
https://issues.apache.org/jira/browse/BOOKKEEPER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484665#comment-13484665
]
Sijie Guo commented on BOOKKEEPER-362:
--------------------------------------
{quote}
Re. 1), it is not just for test. For standalone usage, similar with
LocalDBPersistenceManager, which is not in test.
{quote}
I don't see the code you constructed it for standalone usage. May I miss
something?
{quote}
Re. 2) I would like specific test, as it is more region specific.
Re. 3) regiontopic2version is ZK specific, I do not think it should be in
RegionManager.
{quote}
OK. my point here is that we already have an interface for
RemoteSubscriptionManager, so it would be better to leverage it to hide
specifics under different implementations of RemoteSubscriptionManager. I did
look at the patch again, a minor change might make it clean.
in RegionManager we maintain a mapping from topic to its subscribed regions,
topic => regions. Regions list could be a protobuf encoded metadata when
serialized to MetadataStore.
the interface might be like
{code}
// return a set of regions and it metadata version
void readTopicSubscribedRegions(topic, callback, ctx);
// update region list for a topic
void updateTopicSubscribedRegions(topic, regions, version, callback, ctx);
// remove region list for a topic
void removeTopicSubscribedRegions(topic, version, callback, ctx);
{code}
in RegionManager,
#doRemoteSubscribe, when it failed, it looks into <topic, regions> mapping to
see whether the topic subscribed to remote region. if there is no entry in the
mapping, it called RemoteSubscriptionManager#readTopicSubscribedRegions to
fetch it from MetaStore (ZooKeeper) and put it in the mapping.
#doRemoteSubscribe, when it succeed to startDelivery. it put the region in
<topic, regions> mapping. if it already subscribed to remote region, we don't
need to perform a metadata update. if it was first time to subscribed to remote
region, we perform a metadata update by
RemoteSubscriptionManager#updateTopicSubscribedRegions(topic, regions, version,
callback, ctx)
#onUnsubscribe, perform a metadata remove by
RemoteSubscriptionManager#removeTopicSubscribedRegions(topic, version,
callback, ctx)
using this interface, it also reduces the metadata requests send when subscribe
and unsubscribe, I think. For ZKRemoteSubscriptionManager, it just use one
znode to store its regions list for a topic.
{quote}
Re. 5) the region address is from RegionManager constructor. It is actually the
VIP.
for (final String hub : cfg.getRegions()) {
clients.add(hubClientFactory.create(new HedwigSocketAddress(hub))); }
{quote}
OK. I saw the reason now. We just have address for regions. I had a concern is
that, suppose we have 2 regions, R1 and R2. R1's VIP is r1.vip.xxx.com and R2's
VIP is r2.vip.xxx.com. If at some point, the VIP domain name is changed, the
recored metadata doesn't take any effects and it was hard to clean up.
> Local subscriptions fail if remote region is down
> -------------------------------------------------
>
> Key: BOOKKEEPER-362
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-362
> Project: Bookkeeper
> Issue Type: Bug
> Components: hedwig-server
> Affects Versions: 4.2.0
> Reporter: Aniruddha
> Assignee: Yixue (Andrew) Zhu
> Priority: Critical
> Labels: hedwig
> Fix For: 4.2.0
>
> Attachments: rebase_remoteregion.patch
>
>
> Currently, local subscriptions fail if the remote region hubs are down, even
> if the local hub has subscribed to the remote topic previously. Because of
> this, one region cannot function independent of the other.
> A more detailed discussion related to this can be found here
> http://mail-archives.apache.org/mod_mbox/zookeeper-bookkeeper-dev/201208.mbox/%3cCAOLhyDQSOF+Y+pvnyrd-HJRq1YEr=c8ok_b3_mr81r1g-9m...@mail.gmail.com%3e
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
