This page is meant as a template for writing a DP (DistributedLog Proposal). To create a DP choose DP-Template on creating a page and modify with your content and replace the heading with the next DP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state: [One of  "Under Discussion", "Accepted", "Rejected"]

Discussion thread: [link]

JIRA: [link]

Released:  <DL version>0.5.0

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Describe the problems you are trying to solve.

Public Interfaces

Briefly list any new interfaces that will be introduced as part of this proposal or any existing interfaces that will be removed or changed. The purpose of this section is to concisely call out the public contract that will come along with this feature.

A public interface is any change to the following:

• Data format, Metadata format

• The wire protocol and api behavior

• Any class in the public packages

• Monitoring

• Command line tools and arguments

• Anything else that will likely break existing users in some way when they upgrade

Proposed Changes

By default, DL uses zookeeper as the subscription store. However, zookeeper is not a write-scalable service. So the subscription offset update can not be too frequent, otherwise it would overwhelm the zookeeper service. Besides that, in production environment, it is encouraged to not use zookeeper in a write heavy workload.

Instead, DL/BK is designed for write heavy workload - The log/log segment is naturally good for keeping the history of subscription updates. 

Public Interfaces

No changes to existing public interface.

Proposed Changes

Introduce a log segment based implementation of SubscriptionsStore.

For each subscription in the SubscriptionsStore, it will use a log segment to store the updates for this subscription.

• Metadata Change
  • This change will still use a znode to represent a subscription for backward compatibility. However, instead of storing the subscription updates directly to the znode, the znode will be changed to store the log segment id for the active log segment used by this subscription to store the subscription updates.
  • This change will change to use either protobuf or thrift to store the subscription metadata for extendability in future.

• The proposed format for subscription metadata will be:

  Code Block
  message Subscription { string name = 1; long segment_id = 2; bytes last_commit_dlsn = 3; }   message AdvanceLastCommitDLSN { bytes commit_dlsn = 1; }

• The DLSN for the subscription is either stored in the last record in the log segment or stored as `last_commit_dlsn` in the subscription metadata.
  • last_commit_dlsn will be updated and segment_id will be set to empty when rolling into a new log segment or gracefully shutting down the subscription store.

Configuration Change

There will be a new configuration setting "logSegmentBasedSubscriptionsStoreEnabled". By default it will be disabled. When it is set to true, it would enable log segment based subscriptions storeDescribe the new thing you want to do in appropriate detail. This may be fairly extensive and have large subsections of its own. Or it may be a few sentences. Use judgement based on the scope of the change.

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users? 
• If we are changing behavior how will we phase out the older behavior? 
• If we need special migration tools, describe them here.
• When will we remove the existing behavior?

Test Plan

Describe in few sentences how the DP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

Rejected Alternatives

• The code change will be backward compatible.
• The rollout sequence will be
  • Update all the readers that use subscription store with the latest code and with logSegmentBasedSubscriptionsStoreEnabled disabled.
  • Update all the readers with new configuration with logSegmentBasedSubscriptionsStoreEnabled enabled

Test Plan

N/A

Rejected Alternatives

N/A

 If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.