Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When using bridge runtime directly, it breaks easyadminbundle : Unable to add global "ea" as the runtime or the extensions have already been initialized #58

Open
allan-simon opened this issue Feb 16, 2022 · 8 comments

Comments

@allan-simon
Copy link
Contributor

With this error , EasyCorp/EasyAdminBundle#3715 (comment)

(the work around seems to work)

I think it's because the process is kept alive so some stuff are kept initialized and not cleaned across request ?

@mnapoli
Copy link
Member

mnapoli commented Feb 16, 2022

I think it's because the process is kept alive so some stuff are kept initialized and not cleaned across request ?

Yes, that means that EasyAdmin is incompatible with keeping the process alive. So your options seem to be:

  • don't use EasyAdmin
  • find a way to fix EasyAdmin
  • don't keep the PHP process alive (don't use BREF_LOOP_MAX)

@allan-simon
Copy link
Contributor Author

ok make sense, to the extent of your knowledge, there's no way to have a safety on our side/bref side , to force clean before and/or after a request ? (like unset global variables etc. ) ?

@t-richard
Copy link
Member

The safety on Bref side is not using BREF_LOOP_MAX 😅

There's no way to know what needs cleanup and what doesn't, that is up to the library to decide. That's for the same reason that Symfony provides some tools to make it easier for you to handle such cases but can't handle it in a generic way that would make all code compatible with things like roadrunner, swoole and the likes.

@mnapoli
Copy link
Member

mnapoli commented Feb 18, 2022

@allan-simon why don't you use the standard approach with the FPM layer?

It seems like your application is not compatible with keeping the process alive, and I'd like to understand why you are trying to go that route in that case.

@allan-simon
Copy link
Contributor Author

@mnapoli it seems to come with a significant performance improvement and stack simplification , so why not ?

why did you try to create bref though php is not by default compatible with AWS Lambda ? :)

@allan-simon
Copy link
Contributor Author

@mnapoli I'm revisiting this issue but now I know the "recipe" to solve it

  1. short term: in my codebase decorate services that are problematic and make them implement the kernel.reset tag
  2. long term: try to backport that directly in said libraries

I'm just missing one piece how do I test easily locally this use case using the bref cli and/or docker containers ?

i.e just changing the env variable for the bref/php-81-fpm-dev:2 containers to

        'HANDLER' => 'App\\Kernel',
        'DOCUMENT_ROOT' => 'public',
        'BREF_LOOP_MAX' => '1000',
        'BREF_BINARY_RESPONSES' => '1',

does not seem enough

@mnapoli
Copy link
Member

mnapoli commented Oct 26, 2023

@allan-simon
Copy link
Contributor Author

ah thanks I missed the link to https://github.com/brefphp/dev-server

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants