Показать сообщение отдельно
Старый 23.04.2021, 22:17   #52  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от 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 элементов коллекции между разными системами.
и ни одного внятного рассуждение а как их правильно передать таки.

=========================
спасибо за плодотворное обсуждение.
буду думать.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 23.04.2021 в 22:45.