Comment ChunkMessageChannelItemWriter recueillir des réponses dans spring batch distance de segmentation?

Question

Je suis en train de mettre en œuvre à distance de segmentation dans spring batch à l'aide de spring integration et amqp (rabbitmq).

Je ne suis pas en mesure de comprendre comment ChunkMessageChannelItemWriter recueillir des réponses à distance de segmentation test ci-dessous

https://github.com/spring-projects/spring-batch/blob/master/spring-batch-integration/src/test/resources/org/springframework/batch/integration/chunk/RemoteChunkStepIntegrationTests-context.xml

Comment ça fonctionne ?Est-il envoyer un message, attendre sa réponse, reçoit sa réponse, Puis de nouveau deuxième message, attendre la deuxième réponse à un message et reçoit la deuxième réponse à un message et ainsi de suite ?

Ou envoie tous les messages de manière asynchrone et d'attente pour les réponses et reçoit ensuite les réponses qu'ils arrivent sur la réponse de canal ?

Si nous nous référons à distance de segmentation de la documentation ici

http://docs.spring.io/spring-batch/reference/html/springBatchIntegration.html#asynchronous-processors

il utilise entrants et sortants des adaptateurs.Si ChunkMessageChannelItemWriter reçoit des réponses, pourquoi avons-nous besoin d'adaptateurs ?et à l'esclave côté pourquoi les adaptateurs et les services de l'activateur deux sont utilisés?

Quelqu'un peut-il m'aider à comprendre comment il fonctionne comme il est difficile de comprendre à partir de la documentation.

Answer 1

C'est juste un cas de test, tout fonctionne en local - voir la JMS cas de test pour un exemple plus réaliste.Le canal de l'élément de l'écrivain envoie tous les morceaux de JMS à l'aide d'un sortant de l'adaptateur de canal.

Le côté distant (jms auditeur conteneur) reçoit les morceaux, les traite et envoie les réponses à la replies la file d'attente.

Chaque fois que l'écrivain est appelé à écrire un morceau, il vérifie pour les réponses et les suspend, si nécessaire, si la manette des gaz est dépassée.

Quand tous les morceaux sont écrits, en afterStep(), il attend le reste des résultats.

Tout cela fonctionne de la même façon avec les locaux de cas de test parce que le morceau gestionnaire écrit les réponses à une file d'attente de canal.