DBIx::Connector timeout?

[Anonymous Monk]

Does DBIx::Connector have a limited number of times or limited length of times it tries to connect?

[kcott]

While the short answer to this is no, I get the impression (based on the wording of your question) that there's some underlying assumption you're making that may be wrong. If you have code like:

$DBIx_Connector_object->run(...)

DBIx::Connector may need to reconnect. It doesn't keep a count of how many times it's encountered this situation nor does it keep track of how long it's spent doing this. You won't get an error saying something like: "Sorry, that's the nth time I've encountered run() and needed to reconnect so I won't be trying on this or any subsequent occasions."

DBIx::Connector uses DBI's connect() method with the same arguments you pass to new(), i.e.

DBIx::Connector->new($dsn, $username, $password, { %attributes })

So, if you're familiar with DBI, the actual process of connecting is the same as you're used to.

See Connection Modes, in the DBIx::Connector documentation, for information on when connection checks are made and how reconnecting (and possibly code re-execution) is handled.

[leuchuk]

The timeout comes most probable from the database.

Every database has a predefined timeout. Usually on the clients side there is a parameter for the time wainting for an answer from the server.

There are some solutions for your problem:

First try whether your database is the one giving you this problem. It could be a timeout for example from IP or a wrong routing when e.g. the firewall interrups the traffic.

Then check whether your connection parameters are right. A wrong port number could give you the head ache.

If you identify the database as the one making the timeout: Rise the connection timeout in your database. There is usually an entry in a configuration file or depending on database and OS an environment variable. Rise the limit of open connections if it is a problem of too many open (and probably in parts idle) connections. If you have lots of users try pooling.

Leuchuk