Ce projet explique comment développer un producer/consumer sans la lib interne historique, au profit de celle développée et maintenue par Spring.
Projet d'exemple d'utilisation de la lib org.springframework.kafka:spring-kafka
- Instance
kafka docker&docker-compose(si utilisation dekafka.yml)
Avant de passer à la suite, prendre soin de consulter les ressources ci-dessous:
Entrer dans le container kafka :
docker exec -ti kafka bash
Créer le producer :
kafka-console-producer.sh --broker-list kafka:9092 --topic demo.user --property "parse.key=true" --property "key.separator=|"
Copier les lignes :
112233|{"phoneNumber":"112233", "firstName":"Hubert", "lastName":"Bonisseur de la Bath"}
998877|{"phoneNumber":"998877", "firstName":"Jean", "lastName":"Soudajman"}
446655|{"phoneNumber":"446655", "firstName":"Henri", "lastName":"Tathan"}
Initialiser le topic demo.user par les scripts ci-dessus au préalable
Le script sendSMSDaemon.sh (ressources/pre-init) envoie toutes les 2 secondes un curl de type POST à l'endpoint kafka/sms/send
Important : Nécessite la commande jq
Dernièrement une passe d'alignement des conf des producers et consumers a été opérée par le GLIA, car beaucoup de projets ont été développés par copier/coller par peur de mal faire.
Voici quelques recommendations :
acks=all: c'est maintenant la valeur par défaut, donc inutile de positionnerretries=1: la valeur par défaut est maintenant énorme pour faire des retries quasi indéfiniment, donc inutile de positionnermax.in.flight.requests.per.connection=1: il s'agissait de garantir l'ordre des messages en cas de retry. Je pense que ce besoin est rare et que cette conf ne doit pas être généralisée car on n'a pas la valeur par défaut (5 aujourd'hui)max.request.size>valeur par défaut : ce besoin est réel sur de très rares cas comme le 'producer-otrs' étant donné que l'on a mis les pièces jointes dans le message kafka, mais c'est très rare et doit être supprimé quand ce n'est pas nécessaire car comme toute limite configurable, c'est un garde fou et le fait de le configurer alors que ce n'est pas nécessaire peut induire en erreuractiver les logs Kafka en INFO: par défaut elles sont actives mais on les a désactivés dans pas mal de projets. Aujourd'hui elles manquent cruellement et elles ne sont pas si fréquentes- utiliser le plus possible la configuration via le fichier de conf yaml.