@Internal public class StreamTaskSourceInput<T> extends Object implements StreamTaskInput<T>, org.apache.flink.runtime.io.network.partition.consumer.CheckpointableInput
StreamTaskInput that reads data from the SourceOperator and
returns the DataInputStatus to indicate whether the source state is available,
unavailable or finished.PushingAsyncDataInput.DataOutput<T>UNSPECIFIED| Constructor and Description |
|---|
StreamTaskSourceInput(SourceOperator<T,?> operator,
int inputGateIndex,
int inputIndex) |
| Modifier and Type | Method and Description |
|---|---|
void |
blockConsumption(org.apache.flink.runtime.checkpoint.channel.InputChannelInfo channelInfo) |
void |
checkpointStarted(org.apache.flink.runtime.io.network.api.CheckpointBarrier barrier)
This method is used with unaligned checkpoints to mark the arrival of a first
CheckpointBarrier. |
void |
checkpointStopped(long cancelledCheckpointId) |
void |
close() |
void |
convertToPriorityEvent(int channelIndex,
int sequenceNumber) |
DataInputStatus |
emitNext(PushingAsyncDataInput.DataOutput<T> output)
Pushes elements to the output from current data input, and returns the input status to
indicate whether there are more available data in current input.
|
CompletableFuture<?> |
getAvailableFuture() |
List<org.apache.flink.runtime.checkpoint.channel.InputChannelInfo> |
getChannelInfos() |
int |
getInputGateIndex() |
int |
getInputIndex()
Returns the input index of this input.
|
int |
getNumberOfInputChannels() |
SourceOperator<T,?> |
getOperator() |
org.apache.flink.runtime.jobgraph.OperatorID |
getOperatorID() |
CompletableFuture<Void> |
prepareSnapshot(org.apache.flink.runtime.checkpoint.channel.ChannelStateWriter channelStateWriter,
long checkpointId)
Prepares to spill the in-flight input buffers as checkpoint snapshot.
|
void |
resumeConsumption(org.apache.flink.runtime.checkpoint.channel.InputChannelInfo channelInfo) |
public StreamTaskSourceInput(SourceOperator<T,?> operator, int inputGateIndex, int inputIndex)
public DataInputStatus emitNext(PushingAsyncDataInput.DataOutput<T> output) throws Exception
PushingAsyncDataInputThis method should be non blocking.
emitNext in interface PushingAsyncDataInput<T>Exceptionpublic CompletableFuture<?> getAvailableFuture()
getAvailableFuture in interface org.apache.flink.runtime.io.AvailabilityProviderpublic void blockConsumption(org.apache.flink.runtime.checkpoint.channel.InputChannelInfo channelInfo)
blockConsumption in interface org.apache.flink.runtime.io.network.partition.consumer.CheckpointableInputpublic void resumeConsumption(org.apache.flink.runtime.checkpoint.channel.InputChannelInfo channelInfo)
resumeConsumption in interface org.apache.flink.runtime.io.network.partition.consumer.CheckpointableInputpublic List<org.apache.flink.runtime.checkpoint.channel.InputChannelInfo> getChannelInfos()
getChannelInfos in interface org.apache.flink.runtime.io.network.partition.consumer.CheckpointableInputpublic int getNumberOfInputChannels()
getNumberOfInputChannels in interface org.apache.flink.runtime.io.network.partition.consumer.CheckpointableInputpublic void checkpointStarted(org.apache.flink.runtime.io.network.api.CheckpointBarrier barrier)
CheckpointBarrier. For chained sources, there is no CheckpointBarrier per se flowing
through the job graph. We can assume that an imaginary CheckpointBarrier was produced
by the source, at any point of time of our choosing.
We are choosing to interpret it, that CheckpointBarrier for sources was received
immediately as soon as we receive either checkpoint start RPC, or CheckpointBarrier
from a network input. So that we can checkpoint state of the source and all of the other
operators at the same time.
Also we are choosing to block the source, as a best effort optimisation as: - either there is no backpressure and the checkpoint "alignment" will happen very quickly anyway - or there is a backpressure, and it's better to prioritize processing data from the network to speed up checkpointing. From the cluster resource utilisation perspective, by blocking chained source doesn't block any resources from being used, as this task running the source has a backlog of buffered input data waiting to be processed.
However from the correctness point of view, checkpointStarted(CheckpointBarrier)
and checkpointStopped(long) methods could be empty no-op.
checkpointStarted in interface org.apache.flink.runtime.io.network.partition.consumer.CheckpointableInputpublic void checkpointStopped(long cancelledCheckpointId)
checkpointStopped in interface org.apache.flink.runtime.io.network.partition.consumer.CheckpointableInputpublic int getInputGateIndex()
getInputGateIndex in interface org.apache.flink.runtime.io.network.partition.consumer.CheckpointableInputpublic void convertToPriorityEvent(int channelIndex,
int sequenceNumber)
throws IOException
convertToPriorityEvent in interface org.apache.flink.runtime.io.network.partition.consumer.CheckpointableInputIOExceptionpublic int getInputIndex()
StreamTaskInputgetInputIndex in interface StreamTaskInput<T>public void close()
close in interface Closeableclose in interface AutoCloseablepublic CompletableFuture<Void> prepareSnapshot(org.apache.flink.runtime.checkpoint.channel.ChannelStateWriter channelStateWriter, long checkpointId) throws org.apache.flink.runtime.checkpoint.CheckpointException
StreamTaskInputprepareSnapshot in interface StreamTaskInput<T>org.apache.flink.runtime.checkpoint.CheckpointExceptionpublic org.apache.flink.runtime.jobgraph.OperatorID getOperatorID()
public SourceOperator<T,?> getOperator()
Copyright © 2014–2024 The Apache Software Foundation. All rights reserved.