web-dev-qa-db-fra.com

Kafka INVALID_FETCH_SESSION_EPOCH

Nous utilisons une configuration de courtier kafka avec une application de flux kafka qui s'exécute à l'aide de Spring kafka stream cloud. Bien que cela semble fonctionner correctement, nous obtenons ce qui suit) déclarations d'erreur dans notre journal:

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.

J'ai cherché sur Internet mais il n'y a pas beaucoup d'informations sur cette erreur. J'ai deviné que cela pourrait avoir quelque chose à voir avec une différence de paramètres d'heure entre le courtier et le consommateur, mais les deux machines ont les mêmes paramètres de serveur de temps.

Une idée de comment cela peut être résolu?

apache-kafkaapache-kafka-streamsspring-cloud-stream
11
mmelsen

Il existe un concept de session de récupération, introduit dans KIP-227 depuis la version 1.1.0: https://cwiki.Apache.org/confluence/display/KAFKA/KIP-227%3A+Introduce+Incremental+FetchRequests + à + augmenter + partition + évolutivité

Les courtiers Kafka, qui sont des répliques de followers, récupèrent les messages du leader. Afin d'éviter d'envoyer des métadonnées complètes à chaque fois pour toutes les partitions, seules les partitions modifiées sont envoyées dans la même session d'extraction.

Lorsque nous examinons le code de Kafka, nous pouvons voir un exemple, lorsque cela est retourné:

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#L49

En général, si vous n'avez pas des milliers de partitions et, en même temps, cela ne se produit pas très souvent, cela ne devrait pas vous inquiéter.

4
tgrez

Il semble que cela pourrait être causé par Kafka-8052 problème, qui a été corrigé pour Kafka 2.3.0

6
Dan M

En effet, vous pouvez avoir ce message lors du roulement ou de la suppression basée sur la rétention, comme zen l'a souligné dans les commentaires. Ce n'est pas un problème si cela ne se produit pas tout le temps. Si c'est le cas, vérifiez votre log.roll et log.retention configurations.

1
yuranos87

La mise à jour de la version client vers 2.3 (même version du courtier) le corrige pour moi.

0
Guilherme Torres Castro

Dans notre cas, la cause principale était kafka Incompatibilité courtier - client. Si votre cluster est derrière la version client, vous pourriez voir toutes sortes de problèmes étranges comme celui-ci.

Notre courtier kafka est sur 1.x.x et notre consommateur kafka était sur 2.x.x. Dès que nous avons rétrogradé notre spring-cloud-dependencies à Finchley.RELEASE notre problème a été résolu.

dependencyManagement {
    imports {
        mavenBom "org.springframework.cloud:spring-cloud-dependencies:Finchley.RELEASE"
    }
}
0
so-random-dude