You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "A. Sophie Blee-Goldman (Jira)" <ji...@apache.org> on 2021/04/29 03:44:00 UTC

[jira] [Resolved] (KAFKA-6655) CleanupThread: Failed to lock the state directory due to an unexpected exception (Windows OS)

     [ https://issues.apache.org/jira/browse/KAFKA-6655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

A. Sophie Blee-Goldman resolved KAFKA-6655.
-------------------------------------------
    Resolution: Fixed

This should be fixed, a number of improvements were made around the locking a few versions ago but we actually took it a step further and removing this kind of file-based locking for task directories entirely as of 3.0

> CleanupThread: Failed to lock the state directory due to an unexpected exception (Windows OS)
> ---------------------------------------------------------------------------------------------
>
>                 Key: KAFKA-6655
>                 URL: https://issues.apache.org/jira/browse/KAFKA-6655
>             Project: Kafka
>          Issue Type: Bug
>          Components: streams
>    Affects Versions: 1.0.1
>         Environment: Windows Operating System
>            Reporter: Srini
>            Priority: Major
>
> This issue happens on Windows OS. It code works fine on Linux. This ticket is related to KAFKA-6647, that also reports locking issues on Windows. However, there, the issue occurs if users calls KafkaStreams#cleanUp() explicitly, while this ticket is related to KafkaStreams background CleanupThread (note, that both use `StateDirectory.cleanRemovedTasks`, but behavior is still slightly different as different parameters are passed into the method).
> {quote}[CleanupThread] Failed to lock the state directory due to an unexpected exceptionjava.nio.file.DirectoryNotEmptyException: \tmp\kafka-streams\srini-20171208\0_9
>  at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:266)
>  at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
>  at java.nio.file.Files.delete(Files.java:1126)
>  at org.apache.kafka.common.utils.Utils$1.postVisitDirectory(Utils.java:636)
>  at org.apache.kafka.common.utils.Utils$1.postVisitDirectory(Utils.java:619)
>  at java.nio.file.Files.walkFileTree(Files.java:2688)
>  at java.nio.file.Files.walkFileTree(Files.java:2742)
>  at org.apache.kafka.common.utils.Utils.delete(Utils.java:619)
>  at org.apache.kafka.streams.processor.internals.StateDirectory.cleanRemovedTasks(StateDirectory.java:245)
>  at org.apache.kafka.streams.KafkaStreams$3.run(KafkaStreams.java:761)
>  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>  at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
>  at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  at java.lang.Thread.run(Thread.java:745)
> {quote}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)