Тут без коллбэка. Вы просто в потоке мангуста помимо mg_mgr_poll() делаете еще поиск в очереди. Но тогда возникает проблема — mg_mgr_poll() придется делать с нулевым или очень маленьким таймаутом, т.е. чтобы не ждал новых событий. И тогда вы будете выжирать много CPU. Это и есть последствия того, что совмещаем два разных подхода — многопоточность и асинхронность. Возможно можно как-то обойти, но сейчас в голову пока ничего не идет.
Тогда самое простое — сделать два потока — один под мангуст, другой под работу с базой.
Сделать очередь запросов расшареной (привет блокировки!).
Поток мангуста:
1. Поступил HTTP-запрос — записали в очередь
2. Ищем в очереди запросы, для которых имеются готовые к выдаче ответы от БД и выдаем их клиентам
поток базы:
1. Ищем в очереди еще необработанные запросы
2. Нашли — запрашиваем у базы, получаем от нее ответ, если нужно обрабатываем (обработку вообще можно отдельным потоком сделать), записываем ответ в тот же элемент очереди.
Это если по-простому с блокировками очереди. Сюда можно присобачить семафоры/мьютексы чтобы не было напрасных sleep-ов.
Тогда нужно добавить очередь запросов и мониторинг соединений. Это значительно увеличит код.
Хорошо, чуть позже добавлю.
Запрос к базе может идти в том же потоке, если API базы позволяет. Если не позволяет — да, делаем отдельный поток и городим огород с синхронизацией. Но тогда это значительно нивелирует преимущества данного подхода.
Насчет sqlite не подскажу, для PostgreSQL libpq позволяет делать асинхронные запросы.
Любое соединение с БД — это тоже сокет так или иначе. Так что если API СУБД позволяет асинхрон — вы в дамках :)
Спасибо за отзыв, интересно!
Я полагаю, что на той же.
Работать с одним соединением в разных потоках — плохая идея.
Тут весь плюс именно в асинхронной работе в один поток. Т.е. все что делает основной поток — это сетевой ввод-вывод, без диска, без сложной обработки.
Нужно сохранить conn, и туда выдать ответ, когда он будет готов.
Я для этого делал очереди запросов. Также нужно мониторить соединения, чтобы если оно закрылось — отбраковать все запросы из очереди, которые связаны с данным соединением.
Суммы не скажу, не в курсе.
Бизнес-процессов никаких.
Установка, монтаж оборудования. Установка, настройка ПО, обучение персонала на месте.
ТЗ по накатанной рыбе, причем оно от продукта к продукту отличается не сильно, все в самых общих чертах, абстрактно.
Начнешь делать подробно и потом упираться — себе дороже выйдет, причину не подписать акт всегда найти можно при желании.
«поставка ПО и услуги по внедрению это и так разные договоры» — вы имеете ввиду, если поставщик ПО и интегратор — разные компании? Просто если это одна лавочка, то какой смысл разделять? Ведь одно без другого попросту не нужно?
Дешево и сердито — да. Насчет надежности вопрос спорный. Там уже вопрос упирается в тип сетевой файловой системы. Было много негативного опыта, когда админы настраивали NFS, не удосужившись даже слегка погрузиться в настройки. А между тем по-умолчанию процесс, обращающийся к точке монтирования NFS в режиме hard в случае потери связи с файл-сервером тупо виснет, а в случае если выключена опция intr, виснет очень хорошо. С Samba и CIFS тоже немало глюков. Плюс сложности с резервированием.
Вобщем эта экономия приносит немало бед эксплуатирующему персоналу.
«Правильный подход» на практике практически невозможно реализовать.
Попробуйте встать на сторону Заказчика.
Зачем ему ваш коробочный продукт, если он не выполняет нужных ему функций?
Тут либо вы его сможете убедить, что ему эти функции не нужны (в вашем продукте есть другой метод решения задачи), либо проще найти другой продукт, где эти функции уже есть.
Если же предложенная функция действительно расширит полезный функционал продукта и пригодится другим клиентам, то ее нужно реализовать бесплатно. А если нет — то и за деньги ее вносить не стоит.
Про хранение — спору нет. Речь про методы обмена между приложениями или его частями.
Работаю в сфере где все очень консервативно и направлено на максимально быстрое написание кода, зачастую это как раз через файлы. Одно приложение положило сообщение в файл, другое — сканирует каталог и забирает сообщения из файлов. Вот так вот, в 21-м веке :)
А слать данные можно непосредственно когда их обнаружили в очереди, вне обработчика. Главное в том же потоке мангуста.
Сделать очередь запросов расшареной (привет блокировки!).
Поток мангуста:
1. Поступил HTTP-запрос — записали в очередь
2. Ищем в очереди запросы, для которых имеются готовые к выдаче ответы от БД и выдаем их клиентам
поток базы:
1. Ищем в очереди еще необработанные запросы
2. Нашли — запрашиваем у базы, получаем от нее ответ, если нужно обрабатываем (обработку вообще можно отдельным потоком сделать), записываем ответ в тот же элемент очереди.
Это если по-простому с блокировками очереди. Сюда можно присобачить семафоры/мьютексы чтобы не было напрасных sleep-ов.
Хорошо, чуть позже добавлю.
Запрос к базе может идти в том же потоке, если API базы позволяет. Если не позволяет — да, делаем отдельный поток и городим огород с синхронизацией. Но тогда это значительно нивелирует преимущества данного подхода.
Любое соединение с БД — это тоже сокет так или иначе. Так что если API СУБД позволяет асинхрон — вы в дамках :)
Спасибо за отзыв, интересно!
Работать с одним соединением в разных потоках — плохая идея.
Тут весь плюс именно в асинхронной работе в один поток. Т.е. все что делает основной поток — это сетевой ввод-вывод, без диска, без сложной обработки.
Я для этого делал очереди запросов. Также нужно мониторить соединения, чтобы если оно закрылось — отбраковать все запросы из очереди, которые связаны с данным соединением.
Бизнес-процессов никаких.
Установка, монтаж оборудования. Установка, настройка ПО, обучение персонала на месте.
ТЗ по накатанной рыбе, причем оно от продукта к продукту отличается не сильно, все в самых общих чертах, абстрактно.
Начнешь делать подробно и потом упираться — себе дороже выйдет, причину не подписать акт всегда найти можно при желании.
И хоть ты тресни… :)
Вобщем эта экономия приносит немало бед эксплуатирующему персоналу.
Попробуйте встать на сторону Заказчика.
Зачем ему ваш коробочный продукт, если он не выполняет нужных ему функций?
Тут либо вы его сможете убедить, что ему эти функции не нужны (в вашем продукте есть другой метод решения задачи), либо проще найти другой продукт, где эти функции уже есть.
Если же предложенная функция действительно расширит полезный функционал продукта и пригодится другим клиентам, то ее нужно реализовать бесплатно. А если нет — то и за деньги ее вносить не стоит.
Пока мной RabbitMQ толком не изучен, поэтому и писать нечего.
Работаю в сфере где все очень консервативно и направлено на максимально быстрое написание кода, зачастую это как раз через файлы. Одно приложение положило сообщение в файл, другое — сканирует каталог и забирает сообщения из файлов. Вот так вот, в 21-м веке :)