I'm building a site and it's all fine and well except when randomly getting part of the page (without any css,html) essentially like a semi-half blank page and ,sometimes again, getting a "Reload the page to get source for:" from the GET request using Firebug. Firebug's Net panels shows only the initial GET request but not the subsequent ones to the other resources, like the CSS file, images,Javascripts etc When that happens I get the following in the DBI trace log : " <-- dbd_st_finish 1 <- fetch= ( undef ) [1 items] row1 at /home/starman/perl5/perlbrew/perls/perl-5.18.1/lib/site_perl/5.18.1/x86_64-linux/DBD/ mysql.pm line 867 via at /home/starman/Foo/bin/../lib/MySite/Model.pm line 219 <- fetchrow_hashref= ( undef ) [1 items] row1 at /home/starman/Foo/bin/../lib/MySite/Model.pm line 219 via at /home/starman/Foo/bin/../lib/Foo.pm line 34 <> DESTROY(DBI::st=HASH(0x3fcfc60)) ignored for outer handle (inner DBI::st=HASH(0x3fcfac8) has ref cnt 1) -> DESTROY for DBD::mysql::st (DBI::st=HASH(0x3fcfac8)~INNER) <- DESTROY= ( undef ) [1 items] at /home/starman/Foo/bin/../lib/Foo.pm line 34 via at /home/starman/Foo/bin/../lib/Foo.pm line 34 DESTROY (dbih_clearcom) (sth 0x3fcfac8, com 0x41e4d70, imp DBD::mysql::st): FLAGS 0x180191: COMSET Warn RaiseError PrintError PrintWarn PARENT DBI::db=HASH(0x3d23dc0) KIDS 0 (0 Active) NUM_OF_FIELDS 38 NUM_OF_PARAMS 0 dbih_clearcom 0x3fcfac8 (com 0x41e4d70, type 3) done. <> DESTROY(DBI::db=HASH(0x3d18b00)) ignored for outer handle (inner DBI::db=HASH(0x3d23dc0) has ref cnt 1) -> DESTROY for DBD::mysql::db (DBI::db=HASH(0x3d23dc0)~INNER) imp_dbh->pmysql: 42d7440 <- DESTROY= ( undef ) [1 items] at /home/starman/Foo/bin/../lib/Foo.pm line 34 via at /home/starman/Foo/bin/../lib/Foo.pm line 34 DESTROY (dbih_clearcom) (dbh 0x3d23dc0, com 0x418e4e0, imp DBD::mysql::db): FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn AutoCommit PARENT DBI::dr=HASH(0x3c85940) KIDS 0 (0 Active) IMP_DATA HASH(0x3d23478) dbih_clearcom 0x3d23dc0 (com 0x418e4e0, type 2) done. " The setup is Dancer,Starman,Mysql on Digital Ocean Any help deeply appreciated, thanks!
I should explain more: there are two queries each one in its own sub, the first one being called through a straightforward [% PROCESS tablets.tt %] which populates some elements like drop down select menus,sliders etc When the user makes a choice the second query is fired through an Ajax call: $.ajax({ url: '/query2', type: "POST", data: AllData(1)}).success(function(data){ $("#contentx").append(data); }); which populates a #contentx div with the results of the query. Now,when in the same session, the error does not occur no matter how much I stress it. When opening another 4-5 sessions,or doing a couple of reloads of the same session, the DBI error comes up and I get the effect of the first query being run as the elements are still populated, but then there is nothing else:no css,scripts,and the rest of the html code . Is that indicating a global DBI handle that is reused and cleaned up at some time,having to do with Starman's preforking? The thing is that in my Model I initialize the database and statement handles within the subs scope and not globally. DBD:mysql 4.031 DBI 1.633 Dancer2 0.158000 Ubuntu 14.04 x86_64 x86_64 x86_64 GNU/Linux On Sun, Apr 26, 2015 at 12:56 PM, Nikos Vaggalis <nikos.vaggalis@gmail.com> wrote:
I'm building a site and it's all fine and well except when randomly getting part of the page (without any css,html) essentially like a semi-half blank page and ,sometimes again, getting a "Reload the page to get source for:" from the GET request using Firebug. Firebug's Net panels shows only the initial GET request but not the subsequent ones to the other resources, like the CSS file, images,Javascripts etc When that happens I get the following in the DBI trace log :
" <-- dbd_st_finish 1 <- fetch= ( undef ) [1 items] row1 at /home/starman/perl5/perlbrew/perls/perl-5.18.1/lib/site_perl/5.18.1/x86_64-linux/DBD/ mysql.pm line 867 via at /home/starman/Foo/bin/../lib/MySite/Model.pm line 219 <- fetchrow_hashref= ( undef ) [1 items] row1 at /home/starman/Foo/bin/../lib/MySite/Model.pm line 219 via at /home/starman/Foo/bin/../lib/Foo.pm line 34 <> DESTROY(DBI::st=HASH(0x3fcfc60)) ignored for outer handle (inner DBI::st=HASH(0x3fcfac8) has ref cnt 1) -> DESTROY for DBD::mysql::st (DBI::st=HASH(0x3fcfac8)~INNER) <- DESTROY= ( undef ) [1 items] at /home/starman/Foo/bin/../lib/Foo.pm line 34 via at /home/starman/Foo/bin/../lib/Foo.pm line 34 DESTROY (dbih_clearcom) (sth 0x3fcfac8, com 0x41e4d70, imp DBD::mysql::st): FLAGS 0x180191: COMSET Warn RaiseError PrintError PrintWarn PARENT DBI::db=HASH(0x3d23dc0) KIDS 0 (0 Active) NUM_OF_FIELDS 38 NUM_OF_PARAMS 0 dbih_clearcom 0x3fcfac8 (com 0x41e4d70, type 3) done.
<> DESTROY(DBI::db=HASH(0x3d18b00)) ignored for outer handle (inner DBI::db=HASH(0x3d23dc0) has ref cnt 1) -> DESTROY for DBD::mysql::db (DBI::db=HASH(0x3d23dc0)~INNER) imp_dbh->pmysql: 42d7440 <- DESTROY= ( undef ) [1 items] at /home/starman/Foo/bin/../lib/Foo.pm line 34 via at /home/starman/Foo/bin/../lib/Foo.pm line 34 DESTROY (dbih_clearcom) (dbh 0x3d23dc0, com 0x418e4e0, imp DBD::mysql::db): FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn AutoCommit PARENT DBI::dr=HASH(0x3c85940) KIDS 0 (0 Active) IMP_DATA HASH(0x3d23478) dbih_clearcom 0x3d23dc0 (com 0x418e4e0, type 2) done. "
The setup is Dancer,Starman,Mysql on Digital Ocean
Any help deeply appreciated, thanks!
On 27/04/2015 3:39 am, Nikos Vaggalis wrote:
Is that indicating a global DBI handle that is reused and cleaned up at some time, having to do with Starman's preforking? The thing is that in my Model I initialize the database and statement handles within the subs scope and not globally.
DBD:mysql 4.031 DBI 1.633
If you are doing the database connection management yourself, I strongly suggest you look at DBIx::Connector. Its fork (and thread) safe, so you don't have to worry about such issues :) Hope that helps, Russell.
I'm a bit confused here. When should we use https://metacpan.org/pod/Dancer2::Plugin::Database and when should we use https://metacpan.org/pod/DBIx::Connector ? Unless I've missed something it looks as though Dancer2::Plugin::Database doesn't depend on DBIx::Connector - what's the reason for that? Andrew On Tue, Apr 28, 2015 at 1:04 AM, Russell Jenkins < russell.jenkins@strategicdata.com.au> wrote:
On 27/04/2015 3:39 am, Nikos Vaggalis wrote:
Is that indicating a global DBI handle that is reused and cleaned up at some time, having to do with Starman's preforking? The thing is that in my Model I initialize the database and statement handles within the subs scope and not globally.
DBD:mysql 4.031 DBI 1.633
If you are doing the database connection management yourself, I strongly suggest you look at DBIx::Connector. Its fork (and thread) safe, so you don't have to worry about such issues :)
Hope that helps, Russell.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- Andrew Solomon Mentor@Geekuni http://geekuni.com/ http://www.linkedin.com/in/asolomon
on a similar note, should Mysql be built with the -with-thread-safe-client on ? On Tue, Apr 28, 2015 at 9:16 AM, Andrew Solomon <andrew@geekuni.com> wrote:
I'm a bit confused here. When should we use https://metacpan.org/pod/Dancer2::Plugin::Database and when should we use https://metacpan.org/pod/DBIx::Connector ?
Unless I've missed something it looks as though Dancer2::Plugin::Database doesn't depend on DBIx::Connector - what's the reason for that?
Andrew
On Tue, Apr 28, 2015 at 1:04 AM, Russell Jenkins < russell.jenkins@strategicdata.com.au> wrote:
On 27/04/2015 3:39 am, Nikos Vaggalis wrote:
Is that indicating a global DBI handle that is reused and cleaned up at some time, having to do with Starman's preforking? The thing is that in my Model I initialize the database and statement handles within the subs scope and not globally.
DBD:mysql 4.031 DBI 1.633
If you are doing the database connection management yourself, I strongly suggest you look at DBIx::Connector. Its fork (and thread) safe, so you don't have to worry about such issues :)
Hope that helps, Russell.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- Andrew Solomon
Mentor@Geekuni http://geekuni.com/ http://www.linkedin.com/in/asolomon
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Tue, 28 Apr 2015 07:16:56 +0100 Andrew Solomon <andrew@geekuni.com> wrote:
I'm a bit confused here. When should we use https://metacpan.org/pod/Dancer2::Plugin::Database and when should we use https://metacpan.org/pod/DBIx::Connector ?
Unless I've missed something it looks as though Dancer2::Plugin::Database doesn't depend on DBIx::Connector - what's the reason for that?
D::P::D is designed to: * manage caching of handles, checking them and automatically reconnecting as needed, going to lengths to ensure fork/thread safety * abstract out the reading of DB connection details from the app's config/environment config files (including supporting different named sets of details) * add quick convenience methods to save the amount of SQL you need to write, making simple queries possible in pure-Perl without resorting to DBIC et al. I could have used DBIx::Connector to handle the connecting part, but it was just as easy to implement it myself, without adding an additional prereq - I didn't see the need for DBIx::Connector given that I was writing all the logic to safely cache connection handles etc anyway. -- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github
On Apr 26, 2015, at 3:56 AM, Nikos Vaggalis <nikos.vaggalis@gmail.com> wrote:
When that happens I get the following in the DBI trace log :
" <-- dbd_st_finish 1 <- fetch= ( undef ) [1 items] row1 at /home/starman/perl5/perlbrew/perls/perl-5.18.1/lib/site_perl/5.18.1/x86_64-linux/DBD/mysql.pm line 867 via at
This code is pretty clear about the problem being in the DBI MySQL driver, not in Dancer, so why are you posting here? The only Dancer-related thing I could suggest would be to run the app in Development mode: warnings turn into errors, you get stack traces on the screen when it happens, etc. At the very least, this will help you trace the MySQL error back to the line of code you wrote that causes it. You might get a trap earlier in your code if you’re doing something like making use of an uninitialized variable, which is what is causing the MySQL driver to fail in turn.
participants (5)
-
Andrew Solomon -
David Precious -
Nikos Vaggalis -
Russell Jenkins -
Warren Young