Завершение обмена после объединения

Я получаю сообщения от кролика и агрегирую их. Я заметил, что даже при autoAck=false сообщения подтверждаются, как только они собраны. Это означает, что если мой процесс выйдет из строя, сообщения не будут повторно поставлены в очередь для повторной отправки.

Я подключил leveldb java db в качестве репозитория агрегации, который решает проблему, поскольку я предполагаю, что он будет подтверждаться только после того, как он будет агрегирован и сохранен в репо? Честно говоря, level-db не заставляет меня чувствовать себя комфортно из-за его активности и проблем с версией C, думаю, я могу переключить его на репозиторий SQL.

Так. Вопрос в том, могу ли я что-то сделать, чтобы Camel подтверждал сообщения обмена только после того, как агрегированное сообщение завершило свое путешествие? После агрегации моим следующим шагом будет простая запись на диск.


apache-camel
person Skynet5    schedule 07.07.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

То есть по замыслу агрегатор — это EIP с отслеживанием состояния. Таким образом, входящее сообщение передается агрегатору, а затем продолжается, и, таким образом, потребитель кролика, обработавший сообщение, завершается и получает подтверждение.

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

Поскольку последним шагом является запись на диск, я бы изменил дизайн, чтобы вы брали каждое сообщение от кролика и сначала записывали на диск, а затем делали другое с диска -> агрегат -> диск.

person Claus Ibsen    schedule 07.07.2017
comment
re: дисковый подход. наверняка у меня будет такая же проблема. он переместит файл один раз в совокупности, и если это не удастся, у меня возникнут проблемы. Я не могу потерять сообщения. Похоже, мне нужно использовать постоянное хранилище... но leveldb и hawtdb на самом деле не выглядят достаточно серьезными. позор на самом деле ... поскольку получение из очереди и подтверждение только после пакетной обработки должно быть тривиальным, и его довольно легко написать вручную. Любые другие мысли? - person Skynet5; 07.07.2017
comment
Использование простых файлов лучше, чем хранилище leveldb, так как простыми файлами легче управлять. И, как вы говорите, вам все равно нужно хранить в файлах потом. - person Claus Ibsen; 07.07.2017
comment
так что в этом случае я вообще не буду использовать репозиторий? rmq -> диск1 -> агрегатор -> диск2. Думаю, я пытаюсь понять, что на этапе disk1 потребитель переместит файл, когда он попадет в агрегатор... так что я все еще в том же положении. Если система выйдет из строя... те, что собирались, будут потеряны, а файлы будут перемещены в архив, и мне придется разобраться, что к чему. - person Skynet5; 07.07.2017
comment
Избегайте агг репо и просто используйте файлы. У вас есть сообщение на диске в безопасности, и гораздо проще переместить файлы обратно в папку, чем повторно отправлять сообщения из rabbitmq. - person Claus Ibsen; 07.07.2017
comment
так что на самом деле я думаю, что я понимаю, что это не дает мне того, что мне нужно для отказоустойчивости. Я рад сначала записать на диск из RMQ. Но мое требование к агрегации (ограничение файлов в 20 КБ, на которое вы ответили ранее) должно быть надежным и самовосстанавливаемым. Похоже, как вы говорите, подтверждение RMQ при отправке в агрегатор, хотя по замыслу, убивает поддержку моего варианта использования. Если бы он не подтвердился до завершения агрегации и написания сообщения, система могла бы выйти из строя, и кролик автоматически снова сделал бы эти сообщения доступными. - person Skynet5; 07.07.2017