Bug in CacheWarmer?

[fwiethof]

Hello Johannes,

Since your last commit 93580cb0cdc45795ecbe12a4517d3f2a1e1aba7f it looks like there is a major bug in this bundle (or I am using it incorrectly...).

When using JMSSecurityExtraBundle @Secure annotations for my controller actions, I get error messages like the following:

Fatal error: JMS\DiExtraBundle\HttpKernel\ControllerResolver::{closure}(): Failed opening required '/home/fwiethof/dev/braintower/tools/symfony/app/cache/dev_new/jms_diextra/proxies/Braintower-SecurityBundle-Controller-GroupController.php' (include_path='.:/usr/share/php:/usr/share/pear') in /home/fwiethof/dev/braintower/tools/symfony/app/cache/dev/jms_diextra/controller_injectors/BraintowerSecurityBundleControllerGroupController.php on line 8

(please not the dev_new in the path above)

After reverting back to the previous commit 7409de80a7da2f1accd2efdcb615e74f42549270 this does not occur anymore.

Any idea?

PS: Thanks a lot for your amazing work and your great contributions to the Symfony ecosystem!

[schmittjoh]

Does this happen when you run cache:clear, or when you run cache:warmup? Could you also try manually deleting the cache directory, and just running cache:warmup?

[fwiethof]

When I do a cache:clear, it always happens (also verified by grepping for "dev_new" in the cache directory right after cache:clear).

I did not try cache:warmup. Do you want me to do that?

When I delete the cache directory it behaves just like when I do cache:clear, however, sometimes it does not happen then. When I then gradually readd annotations that I have commented out before (without clearing the cache, just reloading the page in dev environment) the problem eventually occurs (and does not go away until I remove one or more annotations). However, I was not able to consistently reproduce it.

May be its related to the number of annotations, since I did not have the problem at all in the beginning yesterday (I just started to implement security in my application). After I added more and more annotations, it got worse.

-----Ursprüngliche Nachricht----- Von: Johannes [mailto:reply@reply.github.com] Gesendet: Freitag, 1. Juni 2012 02:50 An: Florian Wiethoff Betreff: Re: [JMSDiExtraBundle] Bug in CacheWarmer? (#23)

Does this happen when you run cache:clear, or when you run cache:warmup? Could you also try manually deleting the cache directory, and just running cache:warmup?

---

Reply to this email directly or view it on GitHub: https://github.com/schmittjoh/JMSDiExtraBundle/issues/23#issuecomment-6051331

[stof]

It looks like an issue during the cache warming, referencing the wrong cache folder

[schmittjoh]

Could you try to do a cache:warmup after you have manually removed the cache directory (rm -Rf app/cache/*)?

[fwiethof]

I did this:

fwiethof@hydra:~/dev/braintower/tools/symfony$ php bin/vendors install
You are using the latest composer version.
Installing dependencies from lock file
  - Installing jms/di-extra-bundle (dev-master)
    Cloning bd953ff196ecbb36080eff0c93fb3d735726d26b
Generating autoload files
Installing assets using the hard copy option
Installing assets for Symfony\Bundle\FrameworkBundle into /home/fwiethof/dev/braintower/tools/symfony/web/bundles/framework
Installing assets for Mopa\Bundle\BootstrapBundle into /home/fwiethof/dev/braintower/tools/symfony/web/bundles/mopabootstrap
Installing assets for Braintower\UIBundle into /home/fwiethof/dev/braintower/tools/symfony/web/bundles/braintowerui
Installing assets for Symfony\Bundle\WebProfilerBundle into /home/fwiethof/dev/braintower/tools/symfony/web/bundles/webprofiler
Installing assets for Elao\WebProfilerExtraBundle into /home/fwiethof/dev/braintower/tools/symfony/web/bundles/webprofilerextra
Clearing the cache for the dev environment with debug true
fwiethof@hydra:~/dev/braintower/tools/symfony$ rm -Rf app/cache/*
fwiethof@hydra:~/dev/braintower/tools/symfony$ php app/console cache:warmup
Warming up the cache for the dev environment with debug true

When accessing the URL I had problems with last time, the problem does not occur anymore.

However, when I do:

fwiethof@hydra:~/dev/braintower/tools/symfony$ php app/console cache:clear

or even

fwiethof@hydra:~/dev/braintower/tools/symfony$ rm -Rf app/cache/*          
fwiethof@hydra:~/dev/braintower/tools/symfony$ php app/console cache:clear

it always happens.

[i3or1s]

Hi i am getting the same thing. When i do cache:warmup it is all ok, but if my cache is empty and i do cache:clear i get the error. "Fatal error: Cannot redeclare class appdevUrlGenerator in .../app/cache/dev_new/appdevUrlGenerator.php on line 62"

Entire problem emerged because i was making a warmup class for a MenuBundle that i am trying to build. In this warmup class i am using routing service which reports this fatal error. It is a strange error, i guess it has something to do with shuffling files (dev, dev_new)?

[stof]

@i3or1s if your warmer need to access the router, you need to make it run after the routing cache warmer (there is a priority in cache warmers for this) to ensure that the routing is already warmed up.

[i3or1s]

Thank you for the information this did the trick. By the way this is really ql i did not know that there is a priority attribute.

[schmittjoh]

I looked into this. The problem here is that the cache is built in a different directory, thus require_once does not prevent the same class from being included twice.

Currently, I do not see any feasible fix except simply using the good way to clear your cache rm -rf app/cache/* or removing the cache warmer.

Anyone else with better ideas?

[predakanga]

In lieu of a better solution, would it be possible to throw an exception in ControllerCacheWarmer::warmUp if the cache dir ends in _new (possibly check the current environment vs that for safety)?

It's quite an obtuse error to trace back - for me, it presented itself by pages only half-rendering in production mode; no errors were given at all.

[jmcclell]

So is the answer here to simply not use cache:clear? That seems like a rather unsatisfying response, not that I don't sympathize with the difficulty in solving the issue.

It's odd that it only happens every other cache:clear. Is someone able to articulate why that is, because I'm not seeing why it wouldn't happen on every clear.

[fwiethof]

Hello,

By the way, I agree with that.

Especially because it makes development very inconvenient since when I change a source file, the problem is also triggered in the dev environment. This means, that I have to delete the cache after each change to a file.

So having that fixed would be really great. In the meantime, I’ll stick to the old version.

Best regards, Florian

[bertrandom]

I added a pass that changes the file to the original require_once used, thus avoiding the redeclaration error. I had to use a lookup table but it seems pretty fast, let me know what you think.

[MasterB]

same issue. only rm -rf app/cache/* helps

[schmittjoh]

I have committed a work-around for this problem. Could you try and let me know whether it works for you?

[predakanga]

Your work-around works for me - cache cleared on both dev and prod environments without causing any tests to fail, and without producing any files which reference _new

Thanks, @schmittjoh

[bertrandom]

Works for me, thanks!

[schmittjoh]

Ok, great.

Closing this then.

[fwiethof]

Hello Johannes,

Also works for me. Thanks a lot!

Best regards, Florian

[verschoof]

I think I have the same problem as the topic starter..

php app/console cache:clear --env=prod

Clearing the cache for the prod environment with debug false PHP Fatal error: Cannot redeclare class EnhancedProxy_ed2f3cb92db5d961490e60a593d20b156b460b0d\__CG__\MV\CaravanBundle\Controller\AdminLogController in /home/lepapill/domains/domain.com/app/cache/pro_/jms_diextra/proxies/MV-CaravanBundle-Controller-AdminLogController.php on line 37

composer.json "jms/di-extra-bundle": "1.1.*"

I did try to clear it manually and run the application but that failed.. any ideas?