Mon projet envisage Apache Kafka comme un remplacement potentiel pour une approche de messagerie vieillissante basée sur JMS. Afin de rendre cette transition aussi fluide que possible, il serait idéal que le système de file d'attente de remplacement (Kafka) ait un mécanisme d'abonnement asynchrone, similaire au mécanisme JMS de notre projet actuel consistant à utiliser MessageListener et MessageConsumer pour vous abonner à des sujets et recevoir des notifications asynchrones. Je m'en fiche si Kafka n'est pas strictement conforme à l'API JMS, mais inversement, je préférerais ne pas reconcevoir toute notre suite de classes de publication-abonnement-notification si je n'en ai pas besoin.

Je peux trouver toutes sortes de sondages exemples, mais jusqu'à présent, nous n'avons pas été en mesure de trouver d'exemples avec un client notifié de nouveaux messages via une notification asynchrone.

Est-ce que quelqu'un sait si la version actuelle de Kafka (0.10.2 au moment de cet article) fournit une telle API, ou suis-je obligé d'essayer de réécrire mon code hérité en utilisant le sondage?

6
Ogre Psalm33 21 avril 2017 à 18:12

3 réponses

Meilleure réponse

Les clients Kafka fournissent uniquement un mécanisme de mise en commun à la demande, mais vous pouvez utiliser spring-kafka. Il fournit une interface MessageListener et une annotation KafkaListener et similaire. Consultez la documentation.

1
reynev 21 avril 2017 à 20:14

Vous voudrez peut-être essayer le client JMS Confluent Kafka.

http://docs.confluent.io/3.2.0/clients/kafka-jms-client/docs/index.html

Kafka JMS Client est un wrapper d'API JMS au-dessus de l'API Kafka Producer / Consumer, de sorte qu'il dispose de toutes les interfaces JMS 1.1 standard. Il s'agit d'une fonctionnalité d'entreprise (abonnement), mais si vous téléchargez Confluent Enterprise, vous pouvez l'essayer gratuitement pendant 30 jours.

https://www.confluent.io/download/

0
Hans Jespersen 21 avril 2017 à 22:13

Dans le cas où vous pouvez accepter un peu de latence après avoir consommé tous les messages disponibles, vous pouvez utiliser une minuterie et appeler consumer.poll (0), qui revient immédiatement avec les messages disponibles. Après avoir consommé les messages, vous réglez à nouveau la minuterie avec le même délai acceptable, disons 100 ms.

Lorsque le débit est faible, les lots seront petits et ce délai interviendra plus souvent. Cependant, comme le scénario est asynchrone, le délai n'est pas non plus très critique. De toute façon, vous ne savez jamais exactement quand un message arrive.

Lorsque le débit est très élevé, les lots seront importants. Pour le nouveau consommateur Kafka, la valeur par défaut de fetch.max.bytes est 52428800. Le délai supplémentaire sera relativement faible par rapport au temps nécessaire pour traiter un grand lot de messages.

Vous pouvez envelopper cela dans un petit composant auquel vous attribuez la fonction qui correspond à votre gestionnaire MBean actuel.

0
Werner Donné 12 oct. 2017 à 14:18