docs: Doctrine instability in long-running runtime #243
Conversation
Co-authored-by: Kévin Dunglas <[email protected]>
Co-authored-by: Kévin Dunglas <[email protected]>
Co-authored-by: Kévin Dunglas <[email protected]>
Co-authored-by: Jacob Dreesen <[email protected]>
|
|
||
| ## Doctrine ORM Issues | ||
|
|
||
| Running Symfony with a long-running runtime that leaves worker threads alive, such as the worker mode of FrankenPHP, Swoole or Roadrunner regularly leads to exceptions being thrown when fetching many entities (~100) with Doctrine, every few requests. The worker restarts itself when these exceptions are thrown. |
There was a problem hiding this comment.
| Running Symfony with a long-running runtime that leaves worker threads alive, such as the worker mode of FrankenPHP, Swoole or Roadrunner regularly leads to exceptions being thrown when fetching many entities (~100) with Doctrine, every few requests. The worker restarts itself when these exceptions are thrown. | |
| Running Symfony with a long-running runtime that leaves worker threads alive, such as the worker mode of FrankenPHP, Swoole or Roadrunner regularly leads to exceptions being thrown when fetching many entities (~100) with Doctrine. The worker restarts itself when these exceptions are thrown. |
There was a problem hiding this comment.
It doesn't happen on every request, only on subsequent ones. I have a calendar page traversing a lot of information from different entities with OneToMany relations. Every ~5-10 page visits, php throws a fatal error (typically Fatal Error, Nesting level too deep, recursive dependency?, but sometimes other ones). After reload, it's good for 5-10 visits again and so on.
(I know, I shouldn't use Doctrine for read-only purposes, but efficiency isn't terribly important as the requests still finishes in under 100ms)
There was a problem hiding this comment.
Actually, it would be nice to provide a workaround for that in the docs while it's not fixed upstream.
I'm pretty sure that registering a custom Symfony listener that will call ping() and/or reset the Doctrine connection before using it would fix the issue.
There was a problem hiding this comment.
Yes, I've linked a fix in the issue. You can use the bundle, or just copy-paste the middleware into your own project.
Although, to be honest, I'm not sure why this fixes the issue with doctrine randomly causing bogus php error messages. The memory leak related to doctrine was already fixed sometime in the last months.
There was a problem hiding this comment.
@dunglas do you want to try and document the workaround before merging this PR ?
There was a problem hiding this comment.
@DubbleClick I think that the Doctrine error is triggering another bug in Symfony Error Handler... Would be nice to investigate this one too.
There was a problem hiding this comment.
I've tried to investigate that further in the past, but it didn't really lead anywhere. What prevented the error was limiting the amount of entities I loaded with doctrine. What would be a bug in the Symfony error handler regarding this? That it still renders parts of the template before the crash?
dunglas
changed the title
|
Is still still an issue after the changes they merged regarding |
|
@KDederichs I still have the issue. |
|
I had similar issues with Doctrine and Symfony ... rebooting the kernel between requests fixed it in my case. See php-runtime/runtime#166 |
|
This is now fixed in Symfony! Thanks for your help @vasilvestre!! |
No description provided.