A litte doubt about the usage of checkpointLock

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

A litte doubt about the usage of checkpointLock

aitozi
Hi, community

I see the checkpointLock is used in StreamTask to ensure that we don't have
concurrent method calls that void consistent checkpoints.

As i known, it is used in the data consume , state interactive and the
timerService, But I am doubt that, if an application don't enable the
checkpoint, it still have to deal with the checkpointLock. Is it necessary ?



--
Sent from: http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: A litte doubt about the usage of checkpointLock

Andrey Zagrebin
Hi,

there are at least 3 main players which use the lock to sync state access between each other:
thread processing records in user code, checkpointing thread and processing timers callback thread.

I would still recommend to follow the contract and use the lock where required (e.g. custom source)
because whether it is needed or not eventually depends a lot on internal implementation details which might change. If there is no contention, it will be optimised by JVM and should not degrade performance too much.

Except custom sources as documented, application code is usually not required to deal with the lock in Flink API at all, e.g. in user processing functions.

Cheers,
Andrey

> On 14 Aug 2018, at 09:19, aitozi <[hidden email]> wrote:
>
> Hi, community
>
> I see the checkpointLock is used in StreamTask to ensure that we don't have
> concurrent method calls that void consistent checkpoints.
>
> As i known, it is used in the data consume , state interactive and the
> timerService, But I am doubt that, if an application don't enable the
> checkpoint, it still have to deal with the checkpointLock. Is it necessary ?
>
>
>
> --
> Sent from: http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/