Цитата:
Сообщение от
gl00mie
прямо вот всю коллекцию сразу?
а что об этом сказано в моем утверждении? правильно - ничего.
поэтому варианты на усмотрение отвечающего
Цитата:
Сообщение от
gl00mie
Выходит, вся коллекция может занимать в памяти от нескольких Мб до нескольких сотен Мб, под 1 Гб условно. И это всё - в многопользовательской системе, где параллельно еще десятки процессов тоже что-то лопатят, и им тоже может быть нужно много памяти. Как по мне, так уже на этом этапе решение выглядит неидеальным, лично я предпочел бы начинать отправку сообщений по готовности, а не когда всё-всё будет готово, либо сериализовывал бы их в базу, стараясь избежать затрат в сотни Мб оперативки на одну мою сессию выгрузки данных.
Приемник нежданчиком получает на своей стороне под сотни Мб, теоретически до 1 Гб данных, которые ему потом надо профаршить? А потом на 97% обработки падает - и начинай всё сначала?
о! какое длинное обоснование "как делать не надо".
а как надо?
господи! ну прочитай же первое сообщение!
в аксапте (сюрприз!) данные могут хранится в таблице!
Цитата:
Сообщение от
mazzy
в одной аксапте (назовем ее клиентом) есть огромная коллекция очень важных данных. коллекция - список/массив/мап/контейнер/таблица
щас-щас... наверняка будет текст "как надо".
Цитата:
Сообщение от
gl00mie
На больших объемах подход нужно обычно менять - возможно, в случае с WCF на работу через IEnumerable<>, как тут уже предлагали.
Отлично. И как это сделать из Аксапты? В которой нет генериков.
делать wrapper-объект? накладные расходы на работу wrapper-объекта точно будут меньше, чем накладные расходы при передаче элемента по одному?
"а вы точно режиссёр?"
Цитата:
Сообщение от
gl00mie
Вся тема на форуме - про такие предложения, разве нет?
Таки да!
Цитата:
Сообщение от
gl00mie
Мне кажется, нет тут "правильных" способов, есть способы, которые решают поставленную задачу со всеми ее вводными и ограничениями, есть удобства и стоимости разных решений, есть сложившиеся условия.
Блин, Кайфолом твоя фамилия!
а я так надеялся, что будут рассуждения как сделать правильно.
Цитата:
Сообщение от
gl00mie
К примеру, мне думается, что из брокеров сообщений удобней и быстрее работать с RabbitMQ, но часть клиентов уже внедрила Kafka, и в этих условиях RabbitMQ для них не явлеятся "правильным способом" интеграции систем, потому что у них Kafka является общей шиной данных.
да что вы так упёрлись в серебряные пули в виде Кафки, Кролика, Веб-сферы и т.п. Можно вспомнить и мертвенькую MSMQ (которая уже есть в поставке виндов)
Там тоже есть буфер обмена со своим размером, как в WCF
Там тоже есть потоки, которых нет в Аксапте.
И нет другой магии.
Насколько я понимаю, выбор брокера НИКАК не влияет на рассуждения о том, как правильно передавать 100500 элементов коллекции.
Если вы считаете не так, то просто скажите "1. используем вот это 2. это не буфер ограниченного размера и не поток. 3. и это будет правильно потому-то"
Цитата:
Сообщение от
gl00mie
Упорные попытки выведать волшебный секрет устойчивости 100-метровой башни из пивных банок и отвергание других подходов, мне кажется, ни к чему толковому не приведут, все равно придется переделывать интеграцию. Ну или научиться делать пивные банки 10-метровой высоты
не, у меня полное ощущение, что это
https://xyproblem.info/
что я пытаюсь решить некоторую проблему y, хотя решить надо проблему x...
https://habr.com/ru/company/dododev/blog/467047/
==========================
Чтобы подвести некоторый итог, давайте перечислю варианты, которые здесь прозвучали:
1.
Передавать элементы по одному и не парится
в конечном итоге это может быть и не так уж накладно.
2.
Вручную создавать пакеты (chunks) с некоторым ограниченным числом элементов
можно до опупения добавлять искусственного интеллекта в автоопределение отптимального числа элементов в чанке. Но чем мощнее интеллект, тем больше знаний о транспортном уровне этому интеллекту понадобится. в граничном случае супер-интеллекта придется кодить транспортный уровень вручную. и не факт, что в этом случае накладные расходы получатся меньше, чем при передаче элементов по одному
3.
обмениваться файлами. частный случай пакетов, которые могут быть большими. транспортный уровень нужно кодить
4.
создать свой middleware с блэкджеком и потоками (stream). не решает проблему передачи между аксаптой и middleware. разве что реализовать middleware как dll и внедрить его в адресное пространство AOS. В этом случае передавать между аксаптой и mdllware можно по одному элементу.
5.
магические внешние брокеры , которые по мнению авторов несомненно решат все проблемы, но ни один из авторов не сказал как именно решат.
хипстеры говорят о кролике и кафке, прагматичные говорят о еще живом умертвии msmq и уже готовом адаптере MSMQ в AIF.
самые отважные говорят, что эти внешние брокеры - всего лишь частный случай middleware.
6.
некоторые самые смелые говорят, что для WCF в настройках app.config можно увеличить размер буфера (вместо 65Кб поставить 100Мб, например). Но отводят глаза, когда их спрашиваешь а что будет если кто-то на каком-либо клиенте забудет увеличить размер буфера...
7.
очень нетрадиционный, но очень привлекательный способ -
воспользоваться сервисом Query Service
это не совсем то, о чем спрашивалось.
и не решается вопрос о том, как сделать обмен двусторонним (впрочем о дуплексе в вопросе сознательно не было сказано, признаю)
и разные системы должны слишком много знать о внутреннем устройстве друг-друга.
но... привлекательно, чёрт побьери.
8.
как вариант пункта 7 - публиковать view, а не сервис.
достоинства и недостатки такие же как в пункте 7.
9.
и как же я забыл!
ПДБ - промежуточная база данных.
как частный случай middleware.
=========================
ну и куча отговорок почему не надо передавать 100500 элементов коллекции между разными системами.
и ни одного внятного рассуждение а как их правильно передать таки.
=========================
спасибо за плодотворное обсуждение.
буду думать.