Mailing-List: contact issues-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
From: tony810430 <git@git.apache.org>
To: issues@flink.incubator.apache.org
Reply-To: issues@flink.incubator.apache.org
References: <git-pr-3001-flink@git.apache.org>
In-Reply-To: <git-pr-3001-flink@git.apache.org>
Subject: [GitHub] flink pull request #3001: [FLINK-4821] [kinesis] Implement rescalable non-pa...
Content-Type: text/plain
Message-Id: <20170419074319.DCAC4DFBC8@git1-us-west.apache.org>
Date: Wed, 19 Apr 2017 07:43:19 +0000 (UTC)
archived-at: Wed, 19 Apr 2017 07:43:24 -0000

Github user tony810430 commented on a diff in the pull request:

    https://github.com/apache/flink/pull/3001#discussion_r112134112
  
    --- Diff: flink-connectors/flink-connector-kinesis/src/main/java/org/apache/flink/streaming/connectors/kinesis/FlinkKinesisConsumer.java ---
    @@ -194,26 +216,30 @@ public void run(SourceContext<T> sourceContext) throws Exception {
     		// all subtasks will run a fetcher, regardless of whether or not the subtask will initially have
     		// shards to subscribe to; fetchers will continuously poll for changes in the shard list, so all subtasks
     		// can potentially have new shards to subscribe to later on
    -		fetcher = new KinesisDataFetcher<>(
    -			streams, sourceContext, getRuntimeContext(), configProps, deserializer);
    +		fetcher = createFetcher(streams, sourceContext, getRuntimeContext(), configProps, deserializer);
     
     		boolean isRestoringFromFailure = (sequenceNumsToRestore != null);
     		fetcher.setIsRestoringFromFailure(isRestoringFromFailure);
     
     		// if we are restoring from a checkpoint, we iterate over the restored
     		// state and accordingly seed the fetcher with subscribed shards states
     		if (isRestoringFromFailure) {
    -			for (Map.Entry<KinesisStreamShard, SequenceNumber> restored : lastStateSnapshot.entrySet()) {
    +			List<KinesisStreamShard> newShardsCreatedWhileNotRunning = fetcher.discoverNewShardsToSubscribe();
    +			for (KinesisStreamShard shard : newShardsCreatedWhileNotRunning) {
     				fetcher.advanceLastDiscoveredShardOfStream(
    -					restored.getKey().getStreamName(), restored.getKey().getShard().getShardId());
    +					shard.getStreamName(), shard.getShard().getShardId());
    +
    +				SequenceNumber startingStateForNewShard = lastStateSnapshot.containsKey(shard)
    +					? lastStateSnapshot.get(shard)
    +					: SentinelSequenceNumber.SENTINEL_EARLIEST_SEQUENCE_NUM.get();
    --- End diff --
    
    I just refer the behavior when `KinesisDataFetcher` started consuming data from Kinesis. It always assign `SentinelSequenceNumber.SENTINEL_EARLIEST_SEQUENCE_NUM.get()` for newly discovered shards.
    It's okey to discuss which initial sequence number is proper for new shards here.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---