типа если бы то же самой делалось проксёй, где сохранился бы конструктор с мидлварями, то это была бы полноценная шина, которую можно было бы сконфигурять отдельно именно как шину в framework.messenger

типа если бы то же самой делалось проксёй, где сохранился бы конструктор с мидлварями, то это была бы полноценная шина, которую можно было бы сконфигурять отдельно именно как шину в framework.messenger

Шины и так можно конфигурировать, т.к. шины передаются в декоратор ) Интерфейс тот же что и у шины. Я честно не понимаю в чем проблема ) Поинт был в том что бы сделать отдельный класс под каждую шину, без наследования.

в общем, заработало только не пойму, для чего нужен в конфиге decorate, ибо и без него работает)

в общем, заработало только не пойму, для чего нужен в конфиге decorate, ибо и без него работает)

в общем, заработало только не пойму, для чего нужен в конфиге decorate, ибо и без него работает)

а вот, всё еще перемешиваю кашу) есть два рабочих варианта:

а вот для чего decorate в конфиге пока не догоняю

Кто сказал его добавлять? )

ну вот же: https://symfony.com/doc/current/service_container/service_decoration.html

Помоему вы творите какуюто дичь

$services->set(CommandBus::class)->args([service('command.bus')]) $services->set(EventBus::class)->args([service('event.bus')])

ну, то же самое вроде, только без decorate

ну, то же самое вроде, только без decorate

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

не то что получше, а ваш код работать будет не верно, т.к. автовайринг по классу будет возвращать дефолтную шину.

а в чём принципиальная разница? можно в конфиге бандла сделать: $services ->instanceof(CommandHandlerInterface::class) ->tag('messenger.message_handler', ['bus' => 'command.bus']); а можно в extension::load: $container ->registerForAutoconfiguration(CommandHandlerInterface::class) ->addTag('messenger.message_handler', ['bus' => 'command.bus']); сам framework второй вариант юзает, наверное так же сделаю, но, хотелось бы понять нюансы

а в чём принципиальная разница? можно в конфиге бандла сделать: $services ->instanceof(CommandHandlerInterface::class) ->tag('messenger.message_handler', ['bus' => 'command.bus']); а можно в extension::load: $container ->registerForAutoconfiguration(CommandHandlerInterface::class) ->addTag('messenger.message_handler', ['bus' => 'command.bus']); сам framework второй вариант юзает, наверное так же сделаю, но, хотелось бы понять нюансы

Это хендлеры, а не сервисы

всем привет! подскажите как высвободить память при использовании symfony messenger суть такая, в каждом сообщении сохраняется огромное кол-во данных через доктрину, в начале скрипта потребление 300мб, в конце 3гб, пытаюсь вычистить память в конце скрипта так echo memory_get_usage() . "\n"; - проверил память до очистки, было 3гб $this->entityManager->clear(); $this->managerRegistry->resetManager(); echo memory_get_usage() . "\n"; - проверил после очистки потребление скриптом, стало 300мб echo memory_get_usage(true) . "\n"; - проверил после очистки память выделенную для пхп, стало 3гб в итоге сам скрипт после очистки потребляет снова 300 мб, но для пхп все равно остается выделенная память в размере 3гб, как и до очистки, как эту память высвободить? Спасибо

я демоны просто рестарчу каждые Н итераций :)

он поставляется из коробки, вангую скорее всего в dev режиме запускает

Без true память уменьшилась в десять раз

ну вот да, реально памяти жрется дофига, вот как бы ее высвободить для оси

к симфони не знаю. Мне очень помогало на длинных парсингах, когда отрабатывал пачками страницы - делать unset объектов/переменных. после каждой итерации делал unset всего тяжелого. В итоге пиковое потребление и текущее потребление не отличалось почти. Скрипт сверх лишнего не отжирал. с симфони скорее всего будет тяжело это провернуть.

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

можно попробовать на итерации запускать GC вручную. Может поможет и будет лайт вариантом. Но это если GC будет что собирать. А так да, я вижу (и знаю) только один вариант, чистить доктрину, как самую громоздкую по памяти.

Запуск коллектора проблему не решил

всем привет! подскажите как высвободить память при использовании symfony messenger суть такая, в каждом сообщении сохраняется огромное кол-во данных через доктрину, в начале скрипта потребление 300мб, в конце 3гб, пытаюсь вычистить память в конце скрипта так echo memory_get_usage() . "\n"; - проверил память до очистки, было 3гб $this->entityManager->clear(); $this->managerRegistry->resetManager(); echo memory_get_usage() . "\n"; - проверил после очистки потребление скриптом, стало 300мб echo memory_get_usage(true) . "\n"; - проверил после очистки память выделенную для пхп, стало 3гб в итоге сам скрипт после очистки потребляет снова 300 мб, но для пхп все равно остается выделенная память в размере 3гб, как и до очистки, как эту память высвободить? Спасибо

Здравствуйте! Столкнулся с проблемой, пытаясь поднять проект в докере. Есть 3 контейнера - база, php-fpm, nginx. В php-fpm устанавливаются все зависимости, билдится жс и тд. Такая схема очень часто используется на многих проектах и на гитхабе, и у меня на работе. В конфиге нжинкса есть такая строка: fastcgi_pass php-fpm:9000; fastcgi_index index.php; Как я понимаю, этот контейнер на порте 8000 должен просто кидать на 9000 порт. В общем, это не работает и nginx контейнер использует volume аппликухи без зависимостей. Может, кто-то знает, что я делаю не так?

Ой это такое г..но настройка нгинкса что сложно что-то подсказать