Implement resettable containers #15185

stof · 2015-07-02T22:13:11Z

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	small one
Deprecations?	no
Tests pass?	yes
Fixed tickets	#13448
License	MIT
Doc PR	n/a

This allows to release remove references to all services during shutdown, giving much more chances to destruct services and the container through refcounting rather than waiting GC, as it will break cycles between the container and container-aware services.

There is a small BC break for a very edge case: if someone keeps a reference to the container and then shutdowns the kernel, the container would now be cleared and so would not work as intended anymore. But I don't think it is a supported use case. If you shutdown the kernel, the container of this kernel is released by the kernel and should not be used anymore IMO.
Thus, shutting down the kernel generally does not happen except during tests on teardown.

I'm not sure a doc PR is needed here: users of the fullstack framework should never use this feature (the kernel is using it for them). What do you think @weaverryan ?

stof · 2015-07-02T22:14:25Z

src/Symfony/Component/DependencyInjection/Container.php

+    public function clear()
+    {
+        if (!empty($this->scopedServices)) {
+            throw new RuntimeException('Clearing the container is not allowed when a scope is active.');


note that I added this check because if you are calling clear() while a scope is active, we can be totally sure that it is a misuse of the method.

stof · 2015-07-03T12:41:28Z

I renamed it to ResettableContainerInterface::reset()

mickaelandrieu · 2015-07-03T12:47:25Z

I'm not sure a doc PR is needed here: users of the fullstack framework should never use this feature

And others are not aware of it, sadly. Maybe a little section on http://symfony.com/doc/current/components/dependency_injection/introduction.html is enough, what do you think ?

stof · 2015-07-03T12:48:30Z

@mickaelandrieu it does not belong to the introduction IMO, given it is an edge case feature

Pierstoval · 2015-07-03T12:49:45Z

Maybe this behavior can be used for Testing purpose? When you need to run multiple kernels in a test and check some datas in the container, you may have a reference of it, so clearing the container when shutting the kernel down might be good anyway.

stof · 2015-07-03T12:50:58Z

@Pierstoval I don't understand what you mean

Pierstoval · 2015-07-03T12:59:06Z

For example, when running a phpunit test, one might test compiler passes, so in a single test, he instantiates a first kernel, gets the container and make assertions to check consistency, and then instantiates another kernel, also make assertions on the new container.
In this case, maybe one could keep the container reference even after shutting down the first kernel, so if you clear this reference, no human error is possible when checking the different containers: the first one will be cleared if the associated kernel has been shut down.

I don't know if it's clear enough, but if it's not, then don't mind :p

stof · 2015-07-03T13:03:28Z

@Pierstoval unit testing a compiler pass should not involve booting a kernel (this would be functional testing of the whole app, which is totally inefficient for that).
And anyway, you would still be the one shutting down the kernel if you do it your way. Symfony will not shut down the kernel until the teardown of the WebTestCase.

weaverryan · 2015-07-03T13:43:48Z

I don't think we need to doc anything here :)

stof · 2015-07-03T13:52:25Z

yeah, for the few cases where it could be useful to know about it, we can probably tell developers about this feature.

I'm thinking it might maybe benefit Drupal in their testing environment if they recreate a container each time. As they don't use the kernel, they won't benefit form the automatic usage of the feature. but this would be only once they move to 2.8+ though. /cc @Crell

Tobion · 2015-07-03T13:53:19Z

src/Symfony/Component/HttpKernel/Kernel.php

@@ -13,6 +13,7 @@

 use Symfony\Bridge\ProxyManager\LazyProxy\Instantiator\RuntimeInstantiator;
 use Symfony\Bridge\ProxyManager\LazyProxy\PhpDumper\ProxyDumper;
+use Symfony\Component\DependencyInjection\ResettableContainerInterface;


should be added at the alphabetical order

Tobion · 2015-07-03T13:56:19Z

👍

nicolas-grekas · 2015-07-03T14:14:22Z

src/Symfony/Component/DependencyInjection/Container.php

+    public function reset()
+    {
+        if (!empty($this->scopedServices)) {
+            throw new RuntimeException('Resetting the container is not allowed when a scope is active.');


LogicException?

Nicofuma · 2015-07-06T07:34:11Z

I truly believe it should be documented. Every project using the single components instead of the full stack framework could make use of it and there is some case here it could be very useful.

Maybe an entry in the cookbook? Actually I don't see where it could be in the component documentation... Or just leave it undocumented and rely to the docblock? As you said this feature will not be used by a lot of people.

For the record, phpbb/phpbb:master will make use of it as soon as it will be merged (especially because there is one edge case where we have to build a first container to build the real one (dynamic extension/bundle definition of loading...))

fabpot · 2015-07-06T07:37:36Z

src/Symfony/Component/DependencyInjection/Container.php

@@ -376,6 +376,18 @@ public function initialized($id)
    }

    /**
+     * Clears shared services from the container.
+     */


We should definitely document the side effects of calling this method, not only the intended effects (memory) but also the side effects (a shared service will be re-created if get() is called).

fabpot · 2015-07-14T06:55:25Z

@stof Can you address the comments before merging?

weaverryan · 2015-07-14T19:06:07Z

@Nicofuma Yea, I was thinking that we rely on the PHP documentation for this. And also, since the Container class itself implements the interface, I figure that most people will use that or at least look at it to see how it works (and then they'll notice that resettable stuff). Happy this will be useful for phpbb :)

stof · 2015-07-21T15:52:11Z

updated.

Status: needs review

fabpot · 2015-07-22T03:18:35Z

src/Symfony/Component/DependencyInjection/Tests/ContainerTest.php

+    }
+
+    /**
+     * @expectedException \Symfony\Component\DependencyInjection\Exception\RuntimeException


Should be LogicException, right?

This allows to remove references to all services during shutdown, giving much more chances to destruct services and the container through refcounting rather than waiting GC, as it will break cycles between the container and container-aware services.

nicolas-grekas · 2015-07-22T08:11:40Z

👍

theofidry · 2015-07-22T13:29:42Z

👍

dunglas · 2015-07-22T13:31:37Z

👍

xabbuh · 2015-07-22T20:11:55Z

👍

stof · 2015-07-22T22:52:57Z

FYI, I tried this patch on my work project (I backported the patch on Symfony 2.6 and then ran my Behat testsuite).
Blackfire reports 37% less memory usage, and the time spent in the garbage collector dropped from 37s to 17s (-54%), making the testsuite win several percents of its execution time.
So this is a clear win.

fabpot · 2015-07-23T02:06:24Z

Thank you @stof.

@weaverryan

This PR was merged into the 2.8 branch. Discussion ---------- Implement resettable containers | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | small one | Deprecations? | no | Tests pass? | yes | Fixed tickets | #13448 | License | MIT | Doc PR | n/a This allows to release remove references to all services during shutdown, giving much more chances to destruct services and the container through refcounting rather than waiting GC, as it will break cycles between the container and container-aware services. There is a small BC break for a very edge case: if someone keeps a reference to the container and then shutdowns the kernel, the container would now be cleared and so would not work as intended anymore. But I don't think it is a supported use case. If you shutdown the kernel, the container of this kernel is released by the kernel and should not be used anymore IMO. Thus, shutting down the kernel generally does not happen except during tests on teardown. I'm not sure a doc PR is needed here: users of the fullstack framework should never use this feature (the kernel is using it for them). What do you think @weaverryan ? Commits ------- 4457745 Implement resettable containers

…e/Test/KernelTestCase (nicolas-grekas) This PR was merged into the 2.8 branch. Discussion ---------- [HttpKernel] Don't reset on shutdown but in FrameworkBundle/Test/KernelTestCase | Q | A | ------------- | --- | Bug fix? | yes | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #15185 | License | MIT | Doc PR | - While trying to migrate Blackfire to 2.8-beta, I found this BC-break: by resetting the container on kernel shut-down, functional tests are broken when they need to use the container after a call to `$this->client->request()`. Broken because e.g . the session or the profiler state is lost between consecutive requests in the same test, and because a call to $container->get('kernel') throws a synthetic-related exception. This PR fixes the BC-break by reverting to the <=2.7 behavior (not resetting the container on kernel shut-down), and moving resetting to the KernelTestCase. Commits ------- baad4da [HttpKernel] Don't reset on shutdown but in FrameworkBundle/Test/KernelTestCase

stof reviewed Jul 2, 2015
View reviewed changes

stof force-pushed the clearable_container branch from 3f9eee2 to 715daca Compare July 3, 2015 12:40

stof changed the title ~~Implement clearable containers~~ Implement resettable containers Jul 3, 2015

Tobion reviewed Jul 3, 2015
View reviewed changes

stof force-pushed the clearable_container branch from 715daca to 02ab521 Compare July 3, 2015 14:03

nicolas-grekas reviewed Jul 3, 2015
View reviewed changes

fabpot reviewed Jul 6, 2015
View reviewed changes

stof force-pushed the clearable_container branch from 02ab521 to 1888eff Compare July 21, 2015 15:51

carsonbot added the Status: Needs Review label Jul 21, 2015

fabpot reviewed Jul 22, 2015
View reviewed changes

Implement resettable containers

4457745

This allows to remove references to all services during shutdown, giving much more chances to destruct services and the container through refcounting rather than waiting GC, as it will break cycles between the container and container-aware services.

stof force-pushed the clearable_container branch from 1888eff to 4457745 Compare July 22, 2015 08:09

fabpot merged commit 4457745 into symfony:2.8 Jul 23, 2015

stof deleted the clearable_container branch July 23, 2015 09:48

sstok mentioned this pull request Aug 5, 2015

Symfony 2.5 leaks memory during functional tests #11236

Closed

wouterj mentioned this pull request Aug 22, 2015

Added a note concerning the tearDown method symfony/symfony-docs#4953

Closed

cmodijk mentioned this pull request Sep 3, 2015

Clear container LongRunning/LongRunning#12

Closed

fabpot mentioned this pull request Nov 16, 2015

Release v2.8.0-BETA1 #16550

Merged

nicolas-grekas mentioned this pull request Nov 20, 2015

[HttpKernel] Don't reset on shutdown but in FrameworkBundle/Test/KernelTestCase #16609

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement resettable containers #15185

Implement resettable containers #15185

stof commented Jul 2, 2015

stof Jul 2, 2015

stof commented Jul 3, 2015

mickaelandrieu commented Jul 3, 2015

stof commented Jul 3, 2015

Pierstoval commented Jul 3, 2015

stof commented Jul 3, 2015

Pierstoval commented Jul 3, 2015

stof commented Jul 3, 2015

weaverryan commented Jul 3, 2015

stof commented Jul 3, 2015

Tobion Jul 3, 2015

Tobion commented Jul 3, 2015

nicolas-grekas Jul 3, 2015

fabpot Jul 6, 2015

Nicofuma commented Jul 6, 2015

fabpot Jul 6, 2015

fabpot commented Jul 14, 2015

weaverryan commented Jul 14, 2015

stof commented Jul 21, 2015

fabpot Jul 22, 2015

stof Jul 22, 2015

stof Jul 22, 2015

nicolas-grekas commented Jul 22, 2015

theofidry commented Jul 22, 2015

dunglas commented Jul 22, 2015

xabbuh commented Jul 22, 2015

stof commented Jul 22, 2015

fabpot commented Jul 23, 2015

Implement resettable containers #15185

Implement resettable containers #15185

Conversation

stof commented Jul 2, 2015

Choose a reason for hiding this comment

stof commented Jul 3, 2015

mickaelandrieu commented Jul 3, 2015

stof commented Jul 3, 2015

Pierstoval commented Jul 3, 2015

stof commented Jul 3, 2015

Pierstoval commented Jul 3, 2015

stof commented Jul 3, 2015

weaverryan commented Jul 3, 2015

stof commented Jul 3, 2015

Choose a reason for hiding this comment

Tobion commented Jul 3, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nicofuma commented Jul 6, 2015

Choose a reason for hiding this comment

fabpot commented Jul 14, 2015

weaverryan commented Jul 14, 2015

stof commented Jul 21, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nicolas-grekas commented Jul 22, 2015

theofidry commented Jul 22, 2015

dunglas commented Jul 22, 2015

xabbuh commented Jul 22, 2015

stof commented Jul 22, 2015

fabpot commented Jul 23, 2015