Everything_is_not_so_bad, этот подход понятен и я что-то похожее уже реализовал (через семафоры, которые создают узкое место в процессе обработки - ожидание). Недостаток в том, что если мой сервис упал и успел перед этим набрать к себе в буфер (память) N сообщений из очереди, то все.. в очереди (на сервере) их больше нет, они безвозвратно пропали. Хранить их прямо в БД (чтобы не пропадали при падении) - слишком медленно. Мы как раз хотим избежать лишних обращений к БД.
Everything_is_not_so_bad, я именно про это и спрашиваю: как сказать консьюмеру ibmmq, чтобы он читал только по 1-му сообщению и не читал следующее, пока я не скажу ACK предыдущему?
Нет, это просто некий текстовый идентификатор. И данные эти импортируются в нашу "историю" из внешних систем, сгруппированные по группам (группа синонимов). Нам просто нужно уметь хранить и искать все исторические идентификаторы, которые когда либо входившие в группы.
да, разница между Process.GetCurrentProcess().Threads.Count и ThreadPool.ThreadCount как раз колоссальная. Первый зашкаливает (80+ тыс), второй = 10-15.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.