я именно про это и спрашиваю: как сказать консьюмеру ibmmq, чтобы он читал только по 1-му сообщению и не читал следующее, пока я не скажу ACK предыдущему?
Задача консьюмера - бежать, выполняя задача одну за другой, пока имеются. Они не могут "остановиться", подумать о чем-то или что-то другое.
Чтобы было в нужном темпе, нужно задействовать некоторый буфер, который будет использоваться для накопления задач. Допустим, надо делать батч по 5 задач. И приходит 23 - первый консьюмер кладет их всех в буфер. В то же время другой обработчик (независимый процесс от консьюмеров ibmmq) будет смотреть на буфер в цикле и брать только до 5 задач. Буфер будет увеличиваться и уменьшаться от нуля до того кол-ва задач, которое обработчик, смотрящий на буфер, способен выгребать.
В общем, надеюсь, что уловил идею.
sheich,
тогда консьюмером можно читать по одному сообщению и писать во временный буфер (СУБД, k/v).
Когда сообщение получено и закинуто в буфер - ACK. И по достижению нужного размера (проверяя буфер) что-то делать или просто отправлять в другую очередь.
gidwin,
1. мониторинг нужен. Хоть минимальный. Munin или что-то подобное уже будет неплохо.
2. сколько памяти всего на борту и сколько занимает Redis в обычном режиме?
mayton2019, из изображения получается вектор и все операции поиска делаются по таким же, как и этот.
Полагаю, что речь об этой модели: https://openai.com/index/clip/
Задача консьюмера - бежать, выполняя задача одну за другой, пока имеются. Они не могут "остановиться", подумать о чем-то или что-то другое.
Чтобы было в нужном темпе, нужно задействовать некоторый буфер, который будет использоваться для накопления задач. Допустим, надо делать батч по 5 задач. И приходит 23 - первый консьюмер кладет их всех в буфер. В то же время другой обработчик (независимый процесс от консьюмеров ibmmq) будет смотреть на буфер в цикле и брать только до 5 задач. Буфер будет увеличиваться и уменьшаться от нуля до того кол-ва задач, которое обработчик, смотрящий на буфер, способен выгребать.
В общем, надеюсь, что уловил идею.