"Too many connections" error in a PHPUnit using Zend Framework - zend-framework

I'm unit testing a Zend Framework based project with PHPUnit, it seems like there's too many tests.
Symptoms : I'm writing another test and launching this test on this specific function caused the test to fail with error
Stacktrace :
Zend_Db_Adapter_Exception: SQLSTATE[08004] [1040] Too many connections in /Users/MyUser/workspaces/gitrepo/myprojectcom/webapp/library/Zend/Db/Adapter/Pdo/Abstract.php on line 144
Call Stack:
0.0002 639184 1. {main}() /Users/MyUser/pear/bin/phpunit:0
0.0036 1243552 2. PHPUnit_TextUI_Command::main() /Users/MyUser/pear/bin/phpunit:46
0.0036 1244568 3. PHPUnit_TextUI_Command->run() /Users/MyUser/pear/share/pear/PHPUnit/TextUI/Command.php:130
0.0036 1244568 4. PHPUnit_TextUI_Command->handleArguments() /Users/MyUser/pear/share/pear/PHPUnit/TextUI/Command.php:139
0.0202 5745936 5. PHPUnit_Util_Configuration->getTestSuiteConfiguration() /Users/MyUser/pear/share/pear/PHPUnit/TextUI/Command.php:671
0.0202 5747448 6. PHPUnit_Util_Configuration->getTestSuite() /Users/MyUser/pear/share/pear/PHPUnit/Util/Configuration.php:768
0.0539 6143840 7. PHPUnit_Framework_TestSuite->addTestFiles() /Users/MyUser/pear/share/pear/PHPUnit/Util/Configuration.php:848
0.8321 26889016 8. PHPUnit_Framework_TestSuite->addTestFile() /Users/MyUser/pear/share/pear/PHPUnit/Framework/TestSuite.php:419
0.8329 27067008 9. PHPUnit_Framework_TestSuite->addTestSuite() /Users/MyUser/pear/share/pear/PHPUnit/Framework/TestSuite.php:392
0.8329 27068424 10. PHPUnit_Framework_TestSuite->__construct() /Users/MyUser/pear/share/pear/PHPUnit/Framework/TestSuite.php:318
0.8554 27706232 11. PHPUnit_Framework_TestSuite->addTestMethod() /Users/MyUser/pear/share/pear/PHPUnit/Framework/TestSuite.php:214
0.8555 27706384 12. PHPUnit_Framework_TestSuite::createTest() /Users/MyUser/pear/share/pear/PHPUnit/Framework/TestSuite.php:831
0.8556 27719664 13. ControllerTestCaseAbstract->__construct() /Users/MyUser/pear/share/pear/PHPUnit/Framework/TestSuite.php:554
0.8586 27775696 14. Zend_Application_Bootstrap_BootstrapAbstract->bootstrap() /Users/MyUser/workspaces/gitrepo/myprojectcom/webapp/tests/ControllerTestCaseAbstract.php:24
0.8586 27775696 15. Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap() /Users/MyUser/workspaces/gitrepo/myprojectcom/webapp/library/Zend/Application/Bootstrap/BootstrapAbstract.php:586
0.8586 27775696 16. Zend_Application_Bootstrap_BootstrapAbstract->_executeResource() /Users/MyUser/workspaces/gitrepo/myprojectcom/webapp/library/Zend/Application/Bootstrap/BootstrapAbstract.php:629
0.8586 27776040 17. Bootstrap->_initDb() /Users/MyUser/workspaces/gitrepo/myprojectcom/webapp/library/Zend/Application/Bootstrap/BootstrapAbstract.php:669
0.8590 27782440 18. Zend_Db_Adapter_Abstract->getConnection() /Users/MyUser/workspaces/gitrepo/myprojectcom/webapp/application/Bootstrap.php:97
0.8590 27782440 19. Zend_Db_Adapter_Pdo_Mysql->_connect() /Users/MyUser/workspaces/gitrepo/myprojectcom/webapp/library/Zend/Db/Adapter/Abstract.php:315
0.8591 27782440 20. Zend_Db_Adapter_Pdo_Abstract->_connect() /Users/MyUser/workspaces/gitrepo/myprojectcom/webapp/library/Zend/Db/Adapter/Pdo/Mysql.php:109
To avoid doubt here's my database bootstrap function:
protected function _initDb() {
$databaseConfig = $this->_getDbConfig(); //loaded from an .ini file
$resource = Zend_Db::factory($databaseConfig);
$resource->getConnection();
Zend_Db_Table::setDefaultAdapter($resource);
return $resource;
}
Various other elements :
Commenting one class's test method let me add a this new test case without problem, so the problem doesn't came from my specific new case, but from the amount of test done
I have a very basic _initDb bootstrap function as you can see
This fail also when launching the whole test suite without using "--filter"
My environment is : Mac OS X 10.7.3 Lion, XAMPP's MySQL server 5.1.44, PHPunit 3.6.11 installed through PEAR, PHP 5.3.8
I do close my connection in the tear down [EDIT]
What I'm looking for : any explanation and above all a workaround
Workaround already found : adding a dirty fix in the [mysqld] of /Applications/XAMPP/etc/my.cnf :
set-variable=max_connections=200

You should use closeConnection() from Zend_Db_Adapter.
When you write your web app, there is (usually) no need to explicitly close the connection, because your script starts, executes few queries and ends clearing out all opened connections. In case of your test, you most likely have some long running script, which opens many connections, but since script is not ended, those connections are not cleared out, so yu will have to close them explicitly when you don't need them.

Related

Program and Run PIC18 with pickit4 on linux

I am on linux ubuntu and target is a PIC18F47J53.
I basically want to program the chip and then let it run, using command lines and using pickit4.
using ipecmd (from mplab x ide v5.45), this is my command:
/opt/microchip/mplabx/v5.45/sys/java/zulu8.40.0.25-ca-fx-jre8.0.222-linux_x64/bin/java -jar /opt/microchip/mplabx/v5.45/mplab_platform/mplab_ipe/ipecmd.jar -TPPK4 /P18F47J53 -M -F"/path_to_myfile.hex" -W
This is my output
DFP Version Used : PIC18F-J_DFP,1.4.41,Microchip
*****************************************************
Connecting to MPLAB PICkit 4...
Currently loaded versions:
Application version............00.06.66
Boot version...................01.00.00
Script version.................00.04.17
Script build number............db473af2f4
Tool pack version .............1.6.961
PICkit 4 is supplying power to the target (3.25 volts).
Target device PIC18F47J53 found.
Device Revision Id = 0x1
*****************************************************
Calculating memory ranges for operation...
Erasing...
The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0x3ff
program memory: start address = 0x1fc00, end address = 0x1fff7
configuration memory
Programming/Verify complete
Program Report
30-Jan-2021, 12:54:41
Device Type:PIC18F47J53
Program Succeeded.
Operation Succeeded
All good, and takes about 12 seconds, however, after that the pickit4 turns off the power target, and the pickit LED is BLUE (I guess state "ready")
The main question is how can I let the pickit4 powering the boards? any specific parameter? (I cannot find on the readme.html)
If I use MPLAB X IPE GUI to program, the programming is much quicker (3 or 4 seconds), the pickit LED is YELLOW and the target is left powered on. (I selected "release from reset")
I have tried to get the log out with as many details as possible, but I cannot see the commands sent to the pickit4.
Any idea? thanks
I realize that it's been a while since you asked, but i put the answer here for anyone who needs it. Add -OL to your command line options.

Testing for LibreSSL in a Perl build script

I released Net::NSCAng::Client a while ago and am getting a lot of test failures on OpenBSD. The reason for that is that the NSCAng protocol uses OpenSSL in preshared-key mode (RFC4279), something the folks at LibreSSL (default on OpenBSD now) have ripped out. However, they seem to have been hell-bent on doing this the most intransparent way: the include files have all the functions defined, just the shared library is missing the corresponding symbols, so compilation works fine but the tests fail.
There is a compatibility package on OpenBSD called eopenssl, and by testing for this first in Makefile.PL (using ExtUtils::PkgConfig) I can make it work if the compatibility library is installed. If it isn't, things still fail.
I could check for the CPP symbol OPENSSL_NO_PSK, but as the includes always come from LibreSSL, this fails even if linking with eopenssl would work fine. The only idea I have left is to try and have a test program run as part of the compilation phase as autoconf does it. Is that even possible with ExtUtils::MakeMaker (or something else -- I wouldn't mind switching the build system if necessary)?
It's easy to write feature tests with Devel::CheckLib. Something like the following can be used to check for the presence of function your_func (in Makefile.PL):
my $your_func_exists = check_lib(
header => 'your_header.h',
function => 'return your_func ? 1 : 0;',
);
If you simply want to abort compilation if the function is missing:
check_lib(
...
) or warn('your_func is missing'), exit;
Exiting with 0 should avoid a CPAN Tester's 'FAIL' report.

I keep getting failures installing modules at BEGIN { plan tests => 5 }. What do I need to get past this?

The module it's failing to install is JSON::XS. Really it's failing to install anything
that has the following code:
BEGIN { plan tests => 5 };
From the build.log:
syntax error at t/04_dwiw_encode.t line 13, near "plan tests"
The offending line:
13 BEGIN { plan tests => 5 }
I read that there's a problem with Test.pm but there are quite a few modules
using it and furthermore this just started happening recently.
I just tried reinstalling perlbrew and also tried updating outdated modules
but I keep getting the same failures.
Any one have an idea what might have caused this and how to fix it?
I suspect you either have an older-than-expected version of the Test module, or you created your own module named Test.pm and it's getting picked up instead of the expected module.
You can address the first issue by upgrading Test.
cpan Test
You should address the second issue by renaming your Test.pm to something else, but you might also be able to address it by changing directory and temporarily clearing the PERL5LIB env var.
pushd / ; PERL5LIB= cpan JSON::XS ; popd

CLAPACK: error when testing CBLAS

I am getting an error when i test CBLAS in CLAPACK. When i run the test code
./xblat2d < dblat2.in
I get the error output:
"TransA must be 111, 112 or 113, but is set to -1Parameter 2 to routine cblas_dgemv was incorrect"
Does anyone know what kind of problem this indicates?
Details
I am trying not to use reference CBLAS, and use ATLAS CBLAS instead. So, i compiled wrapper library libcblaswr.a and changed the line in make.inc to
BLASLIB = ../../libcblaswr.a -L/usr/local/atlas/lib -lcblas -L/usr/local/atlas/lib -latlas
CLAPACK installation suggest doing
BLASLIB = ../../libcblaswr.a -lcblas -latlas
But linker doesn't find cblas and atlas without me using -L option, so i included it.
Details of my setup:
Ubunty Lycid Lynx 10.04
CLAPACK-3.2.1
ATLAS.3.9.51
This appears to be a problem with the CLAPACK test in that it passes the wrong parameters to the BLAS routines. In calling dgemv there is an option for the matrix to operate as itself or as the transpose or as the conjugate transpose, corresponding to 111, 112 or 113 (see line 6 of cblas.h). The code in CLAPACK doesn't set the parameter correctly. I haven't looked deep enough to know if this is an issue with just the test or if the issue runs deeper; but I suspect it's just with the test as I haven't run in to this issue using any CLAPACK code.
I have ignored it because 1) I'm not depending on CLAPACK to test the BLAS routines installed by ATLAS and 2) if there's a deeper issue it will cause an error like this rather than produce invalid results, and I'll track it down then.
And yes, the linker won't find -lcblas and -latlas until you install them somewhere normally searched, this is normal.

DBD::Informix connection issues

I'm having somewhat weird problem with DBD::Informix. If I run a simple script like that:
use DBI;
my $dbh = DBI->connect_cached('dbi:Informix:database', '', '');
my $sth = $dbh->prepare('select foo from bar');
...
It works all right. But if I try to do exactly the same from a test script it fails with the following message:
SQL: -25588: The appl process cannot connect to the database server cms_ol.
ISAM: 22: Invalid argument
The only difference I see is that test script is quite heavy on module usage; it is based on Test::More and loads a lot of submodules that are to be tested.
Turning on DBI trace does not provide anything useful (for me, at least). Simple script runs along just fine:
DBI 1.616-nothread default trace level set to 0x0/1 (pid 9685 pi 0) at test_ifx.pl line 6
Note: perl is running without the recommended perl -w option
-> DBI->connect(dbi:Informix:cms#cms_ol, , ****, HASH(0x13fad0))
-> DBI->install_driver(Informix) for solaris perl=5.008009 pid=9685 ruid=106 euid=106
install_driver: DBD::Informix version 2011.0612 loaded from /cms/webdash/lib/arch/DBD/Informix.pm
<- install_driver= DBI::dr=HASH(0x1c8070)
!! warn: 0 CLEARED by call to connect method
-->> DBD::Informix::dbd_ix_db_connect()
CONNECT TO 'cms#cms_ol' - no user info
-->> DBD::Informix::dbd_ix_db_check_for_autocommit()
... and the only difference in trace of the problematic script I see is that it just fails:
DBI 1.616-nothread default trace level set to 0x0/1 (pid 9687 pi 0) at 22_report.t line 5 via 22_report.t line 6
Note: perl is running without the recommended perl -w option
-> DBI->connect_cached(dbi:Informix:cms, , ****)
-> DBI->install_driver(Informix) for solaris perl=5.008009 pid=9687 ruid=106 euid=106
install_driver: DBD::Informix version 2011.0612 loaded from /cms/webdash/lib/arch/DBD/Informix.pm
<- install_driver= DBI::dr=HASH(0xb619bc)
!! warn: 0 CLEARED by call to connect_cached method
-->> DBD::Informix::dbd_ix_db_connect()
CONNECT TO 'cms' - no user info
***ERROR***
SQL: -25588: The appl process cannot connect to the database server cms_ol.
ISAM: 22: Invalid argument
<<-- dbd_ix_db_connect (**ERROR-1**)
<<-- DBD::Informix::dbd_ix_db_connect()
I'm running custom Perl 5.8.9 build in Solaris 9, with latest DBI and DBD::Informix versions, against Informix IDS 9.40UC.
Update: If I try to be a smartass and put a block like that at the top of the heavy test script:
use DBI;
BEGIN { my $dbh = DBI->connect_cached( ... ); print "Connected!\n" if $dbh; }
... it prints like this:
Connected!
Out of memory!
Callback called exit.
END failed--call queue aborted at t/22_report.t line 20.
Callback called exit at t/22_report.t line 20.
BEGIN failed--compilation aborted at t/22_report.t line 24.
My guess is that DBD::Informix conflicts with some of the modules loaded after the connection is made. But which one? That's the question...
Another update: It appears that the above trick does something unwieldy. I tried to load all the modules explicitly by replacing 'use Module' with 'require Module; Module->import'. Pure Perl modules are OK but whenever XS module using XSLoader appears, Perl goes boom with friendly 'Out of memory' message. And if I move Informix connection below module initialization, it works all right - except DBD::Informix fails with the same -25588 error. Boomer. I'm at loss. :(
Another another update: I tried to run the same script with standard Perl 5.6.1 shipped with Solaris 9, using DBI 1.601 (the latest that would compile with Perl 5.6) and DBD::Informix 2011.0612. Same thing, so it's not custom Perl giving me trouble.
I can also add that the test module in question was prototyped using DBD::SQLite and fully works. It is the final test with DBD::Informix that is failing... As usual. :/
Workaround: following e-mail discussion with Jonathan, a workaround was found: addition of streams-based 'onipcstr' connection to Informix server allowed DBD::Informix to connect. Apparently, some XS modules interfere with default shmem-based connection method, although the culprit is unknown at the moment.
Further discussion
Custom-built Perl is, in my experience, easier than the system Perl. I never modify the system's Perl installation (I don't want to break it) so I always build my own.
You appear to have:
Solaris 9 (SPARC?)
Perl 5.8.9
DBI 1.616
DBD::Informix 2011.0612
ESQL/C (CSDK) 2.81
Informix Dynamic Server 9.40
We don't have the detailed sub-version of ESQL/C and IDS (2.81.UC2, 9.40.UC5, or whatever). There's a hint that you are using a 32-bit version of IDS, so probably everything is 32-bit. You are probably aware that 9.40 is no longer supported by IBM (and, indeed, its successor version 10.00 is also out of support). However, superficially, none of that should matter very much. The failing t91lvarchar.t is not a big issue.
Can you run the connect in working and non-working modes with DBI_TRACE=9 set in the environment.
If the trace for the connect operation is too voluminous to go into an update to the question, we'd better take this off-line to the DBD::Informix support channels (that's me, but by email).
The 'ISAM' error of 22 (Invalid argument) is puzzling. I'm curious about what is in your sqlhosts file for this server - the entry for cms_ol specifically. I'm not sure it will reveal anything, not least because you say the sample ESQL/C below (in the 'First hypothesis' section) works OK, and sometimes the Perl connects and sometimes it does not.
I wonder if there is a name conflict somewhere between functions in the shared libraries? That sort of thing will be hell to track.
First hypothesis
Further information received shows that this was not the crucial distinction.
The difference appears to be:
Works: CONNECT TO 'cms#cms_ol' - no user info
Fails: CONNECT TO 'cms' - no user info
The tricky part to explain is why the second fails, especially as the error goes on to mention cms_ol.
The workaround is to specify the server name in the connect string:
DBI->connect(dbi:Informix:cms#cms_ol, , ****, HASH(0x13fad0))
DBI->connect_cached(dbi:Informix:cms, , ****)
The underlying problem is more likely at the ESQL/C level than anything to do with other Perl modules. That is, if you compiled and executed this ESQL/C program, it would fail on cms and work on cms#cms_ol:
int main(int argc, char **argv)
{
$ char *dbs = "cms";
if (argc > 1)
dbs = argv[1];
$ whenever error stop;
$ connect to :dbs;
return 0;
}
You could run it without an explicit database name (or with an explicit 'cms'), and I would expect it to fail. You could run it with 'cms#cms_ol' and I would expect it to pass. The program will say nothing if it passes; it will be obvious when it fails (though the messages will not be beautiful).
There is an outside chance it is something to do with connect_cached; that is a service provided by the DBI module and not by the DBD::Informix module. On the whole though, it is more likely something happening at the ESQL/C level.