Кафка INVALID_FETCH_SESSION_EPOCH - PullRequest
Новая
       63

Кафка INVALID_FETCH_SESSION_EPOCH

0 голосов
/ 22 февраля 2019

Мы используем установку брокера kafka с приложением потоков kafka, которое работает с использованием Spring Cloud Stream Kafka.Хотя кажется, что все работает нормально, мы получаем следующие сообщения об ошибках в нашем журнале: 

2019-02-21 22:37:20,253 INFO kafka-coordinator-heartbeat-thread | anomaly-timeline org.apache.kafka.clients.FetchSessionHandler [Consumer clientId=anomaly-timeline-56dc4481-3086-4359-a8e8-d2dae12272a2-StreamThread-1-consumer, groupId=anomaly-timeline] Node 2 was unable to process the fetch request with (sessionId=1290440723, epoch=2089): INVALID_FETCH_SESSION_EPOCH.

Я искал в Интернете, но об этой ошибке не так много информации.Я догадывался, что это может иметь какое-то отношение к разнице в настройках времени между брокером и потребителем, но обе машины имеют одинаковые настройки сервера времени.

Есть идеи, как это можно решить?

Ответы [ 4 ]

0 голосов
/ 21 августа 2019

В нашем случае первопричиной была кафка Брокер - несовместимость клиента.Если ваш кластер находится за клиентской версией, вы можете увидеть всевозможные странные проблемы, такие как эта.

Наш брокер kafka работает на 1.xx, а наш потребитель kafka был на 2.xx Как только мы понизили нашу spring-cloud-dependencies до Finchley.RELEASE, наша проблема была решена. 

dependencyManagement {
    imports {
        mavenBom "org.springframework.cloud:spring-cloud-dependencies:Finchley.RELEASE"
    }
}
0 голосов
/ 13 мая 2019

Действительно, вы можете получить это сообщение, когда происходит повторное удаление или удаление на основе хранения, как указано в комментариях zen .Это не проблема, если это не происходит постоянно.Если это так, проверьте настройки log.roll и log.retention.

0 голосов
/ 09 июля 2019

Кажется, это может быть вызвано проблемой Kafka-8052 , которая была исправлена ​​для Kafka 2.3.0

0 голосов
/ 22 февраля 2019

Это может быть вызвано проблемами с сетью.

Существует концепция сеанса выборки, введенная в KIP-227 начиная с выпуска 1.1.0: https://cwiki.apache.org/confluence/display/KAFKA/KIP-227%3A+Introduce+Incremental+FetchRequests+to+Increase+Partition+Scalability

Брокеры Kafka, которые являютсяреплики подписчиков, извлечение сообщений от лидера.Чтобы не отправлять полные метаданные каждый раз для всех разделов, только те разделы, которые изменились, отправляются в одном сеансе выборки.

Когда мы смотрим в код Кафки, мы можем увидеть пример, когда это возвращается:

if (session.epoch != expectedEpoch) {
        info(s"Incremental fetch session ${session.id} expected epoch $expectedEpoch, but " +
          s"got ${session.epoch}.  Possible duplicate request.")
        new FetchResponse(Errors.INVALID_FETCH_SESSION_EPOCH, new FetchSession.RESP_MAP, 0, session.id)
      } else {

src: https://github.com/axbaretto/kafka/blob/ab2212c45daa841c2f16e9b1697187eb0e3aec8c/core/src/main/scala/kafka/server/FetchSession.scala#L493

В общем, если у вас нет тысяч разделов и, в то же время, это случается не очень часто, тогдане беспокоить тебя.

...