dwright / dbd-multi Goto Github PK

t/pod-coverage.t always skips all tests. Thus loading Test::Pod::Coverage is pointless and the dependency on it should be removed.

I was getting the following yesterday:

warn: method name prefix 'multi_' is not associated with a registered driver at /usr/local/share/perl/5.20.2/DBD/Multi.pm line 38.

I couldn't get it to go away until I changed two lines:
https://github.com/dwright/DBD-Multi/blob/master/lib/DBD/Multi.pm#L38
from:
DBD::Multi::db->install_method('multi_do_all');
to:
DBD::Multi::db->install_method('x_multi_do_all');

and
https://github.com/dwright/DBD-Multi/blob/master/lib/DBD/Multi.pm#L117
from:
sub multi_do_all {
to:
sub x_multi_do_all {

Per https://metacpan.org/pod/DBI::DBD#Registering-a-new-driver
(And I don't entirely understand why a x_ prefix makes the warning go away. Probably something deep in DBD code that's checking for something. Any other prefix still has that warning.)

If you are writing a driver which will not be distributed on CPAN, then you should choose a prefix beginning with 'x_', to avoid potential prefix collisions with drivers registered in the future. Thus, if you wrote a non-CPAN distributed driver called DBD::CustomDB, the prefix might be 'x_cdb_'.

I also had the thought, maybe something else is using the multi_ prefix causing a conflict? Here are my DBI available:

$ perl -e 'use DBI; print map "$_\n", DBI->available_drivers;'
DBM
ExampleP
File
Gofer
JDBC
Multi   <---
Proxy
SQLite (Multi dependency)
Sponge
mysql

I'm also hoping my meddling with the code to remove warnings is somehow the reason for ("Compilation failed in require") in #4

The t/unavailable-server.t's subtest Direct connection timed out' uses 192.0.2.1 host in a hope the TCP connection will time out. But this is not true in properly configured network because 192.0.2.0/24 destination should be blocked by routers and properly blocked means to return in ICMP error message and that means an operating system will return an error to the process very quickly within the timeout interval. Then the test fails like this:

t/random.t .............. ok
DBI connect('dbname=fake;host=192.0.2.1','fakeuser',...) failed: could not connect to server: No route to host
	Is the server running on host "192.0.2.1" and accepting
	TCP/IP connections on port 5432? at t/unavailable-server.t line 43.

#   Failed test 'Direct connection timed out'
#   at t/unavailable-server.t line 45.
# Pausing up to 10 seconds to test timeout...
DBI connect('dbname=fake;host=192.0.2.1','fakeuser',...) failed: could not connect to server: No route to host
	Is the server running on host "192.0.2.1" and accepting
	TCP/IP connections on port 5432? at /tmp/loop_over_bdir-31667-GGRLsf/DBD-Multi-1.01-0/blib/lib/DBD/Multi.pm line 441.
DBI connect('dbname=fake;host=192.0.2.1','fakeuser',...) failed: could not connect to server: No route to host
	Is the server running on host "192.0.2.1" and accepting
	TCP/IP connections on port 5432? at /tmp/loop_over_bdir-31667-GGRLsf/DBD-Multi-1.01-0/blib/lib/DBD/Multi.pm line 441.
DBI connect('dbname=fake;host=192.0.2.1','fakeuser',...) failed: could not connect to server: No route to host
	Is the server running on host "192.0.2.1" and accepting
	TCP/IP connections on port 5432? at /tmp/loop_over_bdir-31667-GGRLsf/DBD-Multi-1.01-0/blib/lib/DBD/Multi.pm line 441.
# Looks like you failed 1 test of 7.
t/unavailable-server.t .. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/7 subtests 

If you want to test a timeout, you should start a TCP server on localhost, let the test connect to it, but does not provide any PostgreSQL protocol response from the server (or even do not accept the TCP connection, just keep it in conneciton backlog).

We've implemented DBD::Multi in our code exactly as your doc says. We're using mod_perl, and Apache 2.4.x, libdbd-mysql-perl 4.028, libmysqlclient18 5.5.62, (those drivers versions are because of Debian Jessie) latest master branch of this repo (as of this issue), and connecting to AWS Aurora (MySQL 5.6.10a) using DBD::Multi only during read-only queries.

We're caching the $dbd handle through the entire lifetime of an Apache process, and everything seems to work great. However, when I let things go idle for a number of minutes, then come back to my test server and hit reload, I get an error:

Error: Attempt to reload DBD/Multi.pm aborted.
Compilation failed in require at (eval 1889) line 3.

Can you please steer us in the right direction? Should we upgrade our mysql drivers? Is there a bug in DBD::Multi? Should I not be caching $dbd handles throughout an Apache child's life time?

(Also, I've never had the reload aborted error in the past prior to using DBD::Multi. (For many months with no issue.) I'm going to read through all the code and try to figure it out myself also, but DBD/DBI driver stuff is quite a lot to understand.)

Thank you, this module is great!