common: rename error in ProxyGenerator
Hello,
Actually, I have this hapening, I don’t have idea why, I give you my backtrace, this not happen each time I refresh page but some time.
( ! ) Warning: rename(/app/cache/dev/doctrine/orm/Proxies\__CG__MyCommonBundleEntityVisibilityInformation.php.53c3cccd0a5415.53070441,/app/cache/dev/doctrine/orm/Proxies\__CG__MyCommonBundleEntityVisibilityInformation.php): in \vendor\doctrine\common\lib\Doctrine\Common\Proxy\ProxyGenerator.php on line 305
backtrace :
Call Stack
# Time Memory Function Location
18 0.6984 11450624 Doctrine\ORM\EntityRepository->findOneBy( ) ..\UserManager.php:68
19 0.7052 11784056 Doctrine\ORM\Persisters\BasicEntityPersister->load( ) ..\EntityRepository.php:196
20 0.7709 12390192 Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll( ) ..\BasicEntityPersister.php:756
21 0.7709 12390280 Doctrine\ORM\Internal\Hydration\SimpleObjectHydrator->hydrateAllData( ) ..\AbstractHydrator.php:140
22 0.7710 12395136 Doctrine\ORM\Internal\Hydration\SimpleObjectHydrator->hydrateRowData( ) ..\SimpleObjectHydrator.php:48
23 0.7715 12411464 Doctrine\ORM\UnitOfWork->createEntity( ) ..\SimpleObjectHydrator.php:138
24 0.7869 12653744 Doctrine\Common\Proxy\AbstractProxyFactory->getProxy( ) ..\UnitOfWork.php:2676
25 0.7869 12653832 Doctrine\Common\Proxy\AbstractProxyFactory->getProxyDefinition( ) ..\AbstractProxyFactory.php:119
26 0.7882 12666032 Doctrine\Common\Proxy\ProxyGenerator->generateProxyClass( ) ..\AbstractProxyFactory.php:218
27 0.7930 12695936 rename ( ) ..\ProxyGenerator.php:305
About this issue
- Original URL
- State: closed
- Created 10 years ago
- Reactions: 6
- Comments: 22 (6 by maintainers)
Hi @alcaeus
I think I can help here. We recently updated our Symfony/Doctrine MVC application to use an API driven React frontend. All of a sudden this issue starts popping up on some machines.
Why could that be? MVC application was making single requests at a time when in dev mode, where we have proxy class generation set to AUTOGENERATE_ALWAYS, which is not something we want to change as it is the most convenient setting. The new React frontend is making multiple async requests to the Sf/Doctrine backend, and suddenly we get a race condition where a couple of these backend requests are generating and trying to write to that proxy file at the same time.
I tried adding an @ suppressor before the rename call in vendor/doctrine/common/lib/Doctrine/Common/Proxy/ProxyGenerator.php:309 and the problem goes away. I can’t say this is the best solution since it is true that you are now not using the newly generated proxy class, but IMO a race condition with proxy generation set to AUTOGENERATE_ALWAYS and concurrent requests is not just possible, but expected and should be addressed. PHP rename function is known to be not race condition safe and this needs to be addressed if you wish to avoid such issues.
In terms of how to reproduce, I would bet that firing ab against a simple doctrine instance with AUTOGENERATE_ALWAYS will do the job (note, im running windows, it’s possible other filesystems handle this better than ntfs).
For now I can get by with the @ suppressor. It’s not as though I actually need my proxy classes to be regenerated for both of the 2 requests that are milliseconds apart. If I have the time to look into how to make the rename race condition safe I may see if I can put together a PR.
I’m going to close this as
invalid. The issue described by OP is caused by the operating system. The only way I’ve managed to reproduce it was in a Docker machine whererename('a/file.tmp', 'a/file');caused a cross-device rename due to the union filesystem in use there, and even then I didn’t get it to consistently break.Without at least a consistent way to reproduce this, there’s nothing for us to fix. So please, instead of being the next person to add a
+1type comment, please provide information that is not yet present or try to build a reproducible test case for the problem. Thank you!Note that for production environment you should always pre-generate the proxies (i.e. on your CI or during cache warmup) to not rely on lazy generation (which is prone to race conditions).