Почему происходит сбой приложения Kafka Streams с AccessDeniedException в Windows для очистки состояния? - PullRequest
0 голосов
/ 24 января 2019

Кафка Потоки 2.1.0 на MS Windows здесь.

Я нахожусь на macOS, поэтому не могу работать с ним сам, но работая с людьми, которые работали в MS Windows, они сообщали java.nio.file.AccessDeniedException, когда они использовали KafkaStreams.cleanUp в приложении Kafka Streams каждый время, когда они запустили приложение (кроме первого раза).

В При удалении тем возникает исключение # 196 . Был задан вопрос, почему приложение Kafka Streams не может работать с java.nio.file.AccessDeniedException при запуске EmbeddedSingleNodeKafkaCluster#deleteTopicsAndWait.

Caused by: java.nio.file.AccessDeniedException: C:\Users\gwade\AppData\Local\Temp\junit6747789160683566966\junit5490786451417386230\topic-0 -> C:\Users\gwade\AppData\Local\Temp\junit6747789160683566966\junit5490786451417386230\topic-0.a3c80cfca5e740bd8c1be434d817af2c-delete
        at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83)
        at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
        at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:387)
        at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
        at java.nio.file.Files.move(Files.java:1395)
        at org.apache.kafka.common.utils.Utils.atomicMoveWithFallback(Utils.java:809)
        at kafka.log.Log$$anonfun$renameDir$1.apply$mcV$sp(Log.scala:728)
        at kafka.log.Log$$anonfun$renameDir$1.apply(Log.scala:726)
        at kafka.log.Log$$anonfun$renameDir$1.apply(Log.scala:726)
        at kafka.log.Log.maybeHandleIOException(Log.scala:1927)
        at kafka.log.Log.renameDir(Log.scala:726)
        at kafka.log.LogManager.asyncDelete(LogManager.scala:842)
        at kafka.cluster.Partition$$anonfun$delete$1.apply(Partition.scala:353)
        at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:251)
        at kafka.utils.CoreUtils$.inWriteLock(CoreUtils.scala:259)
        at kafka.cluster.Partition.delete(Partition.scala:347)
        at kafka.server.ReplicaManager.stopReplica(ReplicaManager.scala:350)
        at kafka.server.ReplicaManager$$anonfun$stopReplicas$2.apply(ReplicaManager.scala:380)
        at kafka.server.ReplicaManager$$anonfun$stopReplicas$2.apply(ReplicaManager.scala:378)
        at scala.collection.Iterator$class.foreach(Iterator.scala:893)
        at scala.collection.AbstractIterator.foreach(Iterator.scala:1336)
        at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
        at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
        at kafka.server.ReplicaManager.stopReplicas(ReplicaManager.scala:378)
        at kafka.server.KafkaApis.handleStopReplicaRequest(KafkaApis.scala:200)
        at kafka.server.KafkaApis.handle(KafkaApis.scala:111)
        at kafka.server.KafkaRequestHandler.run(KafkaRequestHandler.scala:69)
        at java.lang.Thread.run(Thread.java:748)

Есть идеи, что является основной причиной?

1 Ответ

0 голосов
/ 24 января 2019

Обходным решением было выключить Zookeeper и удалить /tmp/zookeeper (который просто удалял все состояние кластера Kafka, включая темы, которые должны быть удалены с их локальными каталогами на брокерах).

...