Doctrine PHPCR holding database connections open?

[Darren Black]

I'm getting failing tests when including the DoctrinePHPCRBundle into an existing application. The error I get is as follows:

SQLSTATE[08006] [7] FATAL:  remaining connection slots are reserved for non-replication superuser connections

Any ideas how i might figure this out? For background, I'm using Postgres, Behat for my end-to-end testing, and the Doctrine ORM Purger to clean up the database between scenarios. I have seen a similar issue in the past (with the KnpMenu, which was fixed with this pull request).

Regards

Darren

[David Buchmann]

looks a lot like "something" is keeping open connections. could you
explicitly close the connection in a teardown method of the tests?

On 28.05.2014 08:55, Darren Black wrote:
> I'm getting failing tests when including the DoctrinePHPCRBundle into an
> existing application. The error I get is as follows:
>
> SQLSTATE[08006] [7] FATAL: remaining connection slots are reserved for
> non-replication superuser connections
>
> Any ideas how i might figure this out? For background, I'm using
> Postgres, Behat for my end-to-end testing, and the Doctrine ORM Purger
> to clean up the database between scenarios. I have seen a similar issue
> in the past (with the KnpMenu

> <https://github.com/KnpLabs/KnpMenuBundle/issues/198>, which was fixed
> with this pull request <https://github.com/KnpLabs/KnpMenu/pull/108>).
>
> Regards
> Darren
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to symfony-cmf-us...@googlegroups.com
> <mailto:symfony-cmf-us...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

--
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch

[Darren Black]

Ok, I'm now calling close on the dbal\connection in a teardown method after each scenario - it appears to buy me more time, but it still bombs out. Are there any methods in the phpcr that i might be able to call to make it release the db connection? 

On Wednesday, May 28, 2014 5:22:42 PM UTC+10, David Buchmann wrote:

looks a lot like "something" is keeping open connections. could you
explicitly close the connection in a teardown method of the tests?

On 28.05.2014 08:55, Darren Black wrote:
> I'm getting failing tests when including the DoctrinePHPCRBundle into an
> existing application. The error I get is as follows:
>
> SQLSTATE[08006] [7] FATAL:  remaining connection slots are reserved for
> non-replication superuser connections
>
> Any ideas how i might figure this out? For background, I'm using
> Postgres, Behat for my end-to-end testing, and the Doctrine ORM Purger
> to clean up the database between scenarios. I have seen a similar issue
> in the past (with the KnpMenu
> <https://github.com/KnpLabs/KnpMenuBundle/issues/198>, which was fixed
> with this pull request <https://github.com/KnpLabs/KnpMenu/pull/108>).
>
> Regards
> Darren
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to symfony-cmf-us...@googlegroups.com

> <mailto:symfony-cmf-users+unsub...@googlegroups.com>.

[Lukas Kahwe Smith]

On 29 May 2014, at 00:48, Darren Black <dbl...@totaltrash.net> wrote:

> Ok, I'm now calling close on the dbal\connection in a teardown method after each scenario - it appears to buy me more time, but it still bombs out. Are there any methods in the phpcr that i might be able to call to make it release the db connection?

are you sure there is no setup routing that creates additional connections somewhere?

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Darren Black]

No, there's none. The only difference I have between my working test suite, and the broken one is including DoctrinePHPCRBundle to AppKernel, and the config hooking it into the default connection.

[Lukas Kahwe Smith]

On 29 May 2014, at 01:13, Darren Black <dbl...@totaltrash.net> wrote:

> No, there's none. The only difference I have between my working test suite, and the broken one is including DoctrinePHPCRBundle to AppKernel, and the config hooking it into the default connection.

are you certain you are only firing up one instance of the container? depending on how you for example setup fixtures etc, you might end up creating multiple separate container instances.

[Darren Black]

Well, I believe so! I am using Behat, and using its Symfony extension to get a kernel by implementing the KernelAwareInterface in my FeatureContext (see http://extensions.behat.org/symfony2/#usage) - all my interactions with the container are via this kernel instance,.. Behat reboots the kernel on each scenario, and I'm not booting one elsewhere.

[Darren Black]

And all fixtures are loaded using the orm, pulled from the container via this single kernel (that gets rebooted after each scenario)

[Darren Black]

I'm trying to modify a fork of Symfony SE using phpunit to reproduce the error - I can't replicate the problem so far... so it is probably something i am doing wrong with Behat. 

[Darren Black]

Wow, I nailed it (after about 4 hours of pulling hair out!). I think there is an issue with DoctrinePHPCRBundle holding connections - but only when framework.profiler.collect = true. I can get a test bed application up on github if it helps?

[Lukas Kahwe Smith]

On 29 May 2014, at 07:18, Darren Black <dbl...@totaltrash.net> wrote:

> Wow, I nailed it (after about 4 hours of pulling hair out!). I think there is an issue with DoctrinePHPCRBundle holding connections - but only when framework.profiler.collect = true. I can get a test bed application up on github if it helps?

That could indeed be helpful, but this already gives me a pointer.
Will try to investigate on my 8 hour train ride today :)

[Darren Black]

Ok, I hope it's not too much of a mess (I'm running out of hours in the day) - https://github.com/totaltrash/symfony-standard/commits/test-phpcr

This is based on 2.4 Symfony standard edition. I am finding that running the phpunit tests at commit a41da98754 run fine. Then, when running the same test (after the phpcr bundle is installed) at commit bba642e02c, the tests fail.

I doubt you'll see an issue if you run it with sqlite (does it restrict to a number of connecting clients?) - I'm getting the problem with postgres.

Enjoy the ride!

You can ignore the Behat stuff - i stuck that in there when i was desperately looking for a solution!

[Lukas Kahwe Smith]

On 29 May 2014, at 09:31, Darren Black <dbl...@totaltrash.net> wrote:

> Ok, I hope it's not too much of a mess (I'm running out of hours in the day) - https://github.com/totaltrash/symfony-standard/commits/test-phpcr
>
> This is based on 2.4 Symfony standard edition. I am finding that running the phpunit tests at commit a41da98754 run fine. Then, when running the same test (after the phpcr bundle is installed) at commit bba642e02c, the tests fail.
>
> I doubt you'll see an issue if you run it with sqlite (does it restrict to a number of connecting clients?) - I'm getting the problem with postgres.
>
> Enjoy the ride!
>
> You can ignore the Behat stuff - i stuck that in there when i was desperately looking for a solution!

Sorry .. still didn’t get to it .. hoping tomorrow or thursday will let me work on this :-/

[Darren Black]

No worries, thanks for the update

[Lukas Kahwe Smith]

Finally spending a bit of time with this ..

I am just running:

phpunit -c app

and I am also seeing "SQLSTATE[08006] [7] FATAL: sorry, too many clients already (500 Internal Server Error)”

when I disable DoctrinePHPCRBundle .. things take a while but I end up with green.
when I disable just the queries in the controller, then I end up hitting my ulimit of open files, but I do not think that this is part of your issue.

now I looked a bit further and found that I dealt with a similar issue already:
https://github.com/symfony/symfony/issues/2514
https://github.com/symfony/symfony/issues/2672#issuecomment-2787425