блин, нашел. одной строчкой выше же





ок, теперь понятно почему в без анотаци падало. один единственный бин и ему меняют ... а все это время работало потому, что именно этот метод был по synchronize. поток вызовов вырос, synchronize начал создавать проблемы, а без него ... вот оно что. я почти начал понимать как оно у меня работает



а, наверно в одном только тесте мало поменять на RestOperations, надо было же во всем коде подменить, остальной код тоже же автовайрит ...
попозже попробую.

вы на меня наговариваете
не было беспомощности, я сразу начал обвинять restTemplate в отсутствии thread safe



до этих выходных так и работало: б24 слал рест запрос в апп1, апп1 писала в mariadb и дергала апп2, апп2 шла в б24 выясняя, что собственно обновилось в б24. в итоге все всех ждали. и в принципе эта схема работала, пока летом я не заметил "11-го пользователя" - какой-то робот массово что-то в товарах меняет. мои приложения параллельно получают сотню вызовов и я испугался за б24, если я в рамках своей тупой схемы буду делать сотни реквестов разом в б24, ему поплохеет. вот тут я и бахнул не долго думая synchronize только на обработчик товаров. интересно, что мина сработала лишь спустя пол года.

ладно, на выходных я все общение переделал отдельными тредами. апп1 получая от б24 реквест отвечает 200, в отдельном потоке оповещает апп2, апп2 тоже сразу отвечает 200, в отдельном потоке стартует бизнес логику. synchronize я убрал, но теперь мне нужно думать, как при массовом обновлении товаров в ответ не заддосить б24.
как я понимаю самое правильное было бы городить полноценную очередь, может у спринга что-то такое есть, относительно полноценное но в mysql базе, без messanging quene типа кафки и кролика.

без очередей и синхронно это сколько запросов получил я столько же навалится на б24, а тот не факт, что сдюжит. апп1 спасает от полного фейла, если я завтра снова накосячу с synchronize в апп2 и апп2 встанет колом, то я смогу исправить, передеплоить, найти еще косяк, снова передплоить, но быть уверенным, что апп1 все это время пишет задания и я пропущенные вызовы, пусть и с опазданием, но обработаю.


у меня есть опыт со спарком на основной работе и уже есть приложение на спарке в этом проекте ... да, шедуллер на spark streaming, читает из кафки и запускает нужный процессинг звучит как страница кода, но меня пока пугает администрирование кафки. но в связке с уже имеющимся спарк может оно и ничего.


а чем реакт может помочь в регулировании потока вызовов в сторону б24 ? это же просто колбэк функции, много прилетит ко мне, много вылетит и от меня.

ок, попробую нарисовать поток данных сверху вниз.

1) 1с склады, 1с может быть инициатором массовых обновлений товара в битрикс24, думаю остатков. пока сталкиваюсь порядка 200 одновременных событий.
2) битрикс24 црм, тут 10 пользователей + некие роботы, они могут десятки событий, например задачи генерировать. битрикс24 не может послать в рест вызов, что именно у него изменилось. там можно подписаться лишь на оповещение о том что такая-то сущность изменилась. вот такие оповещения по рест битрикс24 шлет в ап1.
3) апп1 - записывает факт вызова в табличку с автоинкрементом, отвечает 200 на вызовы от б24 и в отдельном потоке дергает апп2. задача апп1 не пропустить ни одного вызова б24 и работать в моменты когда я редеплою или решаю проблемы апп2.
4) апп2 - получает вызовы от апп2, с выходных тут же отвечает 200 и в отдельном потоке процессит события. задачи решает разноплановые:
- постройка витрин для отчетной системы (строит исторические таблицы, т.к. црм не хранит историю)
- синхронизирует данные с инет магазинчиком (синхронизирует товары, сделки, клиентов)
- контролирует некоторые бизнес процессы б24, например при выполнении складским работником б24 задачи, дергает бизнес процесс.
- помогает с массовыми загрузками, периодическими выгрузками.
5) инет магазинчик получает рест вызовы от апп2 если апп2 решило что изменение в товаре или сделке должно отобразится в инет магазине
6) powerbi отчетики, поверх витрин построенных апп2

так вот возвращаясь к вопросу, ждать послезавтра нельзя. послезавтра сделка уже пару стадий сменит и апп2 в исторических таблицах много интересного пропустит. поэтому ради витрин истории, некоторые вещи, желательно обработать поскорей, что бы застать как можно больше изменений. если сделка в течении пары минут изменилась несколько раз, апп2 что-то пропустит, но все таки трагедии не будет. пострадает точность прогнозов и отчетики, но если речь о минутах, то не критично страдает.
у покупателя инет магазинчика тоже не будет трагедии если он увидит статус заявки опозданием несколько минут, но часы уже могут породить вопросы.

я размышляю на счет spark + kafka, но еще не уверен, что готов именно админить кафку. если сломается оракл или mysql, я знаю что такое redo, как починить в любой ситуации. просто запустить кафку по инструкции не выйдет, надо понимать куда бежать, если она поломается.

и еще есть такой вопрос, допустим апп1 пишет в один единственный топик кафки, апп2 читает этот топик, но у меня такой нюанс, что в сделке 100 позиций товара, я пытаюсь сохранить остаток товара в момент создания сделки. для этого я делаю запрос на сущность сделки и 100 запросов в на каждую позицию в сделке, что бы выяснить остаток в сущности товар.
вероятно мне нужно 2 топика, в первом от апп1, одно сообщение, во втором 101 сообщение. выходит апп2 будет само себе сообщение слать. как-то ...

получает вызовы от апп1, конечно же, и забыл самое главное - на каждый событие, делает минимум один рест колл в б24, запрашивая сущность, по которой произошло событие (сделку, товар, задачу, контакт, и т.п.). при этом в случае со сделкой анализирует таблицу событий (записанной апп1) и выфильтровывает дублирующие сообщения на тему сделки, в случае с товаром анализирует кол-во запросов и пытается ограничивать кол-во одновременных запросов в битрикс24, что бы не заддосить сервис.

нет.
вы на каждую стрелочку лишь наплодите больше бестолковых и неинтересных мне вопросов. остальные как я вижу и так понимают, что я пытаюсь надизайнить.