[ic] mysql having problems reconnecting on catalog reconfig
mike at perusion.com
Thu Nov 10 14:19:36 UTC 2011
Quoting Mike Heins (mike at perusion.com):
> Quoting Peter (peter at pajamian.dhs.org):
> > I'm having problems with IC 5.7 (latest GIT HEAD), perl 5.12.4 and
> > mysql. When a catalog reconfig is done none of the sql tables would
> > load back up all giving errors like this in catalog.cfg:
> > table 'variants' failed: table variants connect failed -- unknown error.
> > Driver 'mysql' installed?
> > I traced the problem down to DBI.pm and found that if I change line 372
> > from:
> > $db = DBI->connect( @call ) unless $bad;
> > ...to:
> > $db = DBI->connect( @call );
> > ...then everything now works again. It would seem that for some reason
> > the ached connection goes bad, but it all comes back to life if I allow
> > an attempt to go through to reconnect.
> > I then checked the git logs to find out the history behind that line of
> > code and traced it back to this commit:
> > https://github.com/interchange/interchange/commit/17a12070#L0R372
> > I'm not sure I really understand what the problem was that was fixed
> > back in 2001 by this commit, but perhaps someone (Mike?) could shed some
> > light on it? It seems to make sense to me to try to connect again if
> > the connection goes bad, so why are we not doing that now? Is there any
> > other light that can be shed on this problem?
> It's a part of the alternate DSN stuff, where you can fall back to a
> different database server if one is down.
> But the bigger question is -- why did your connect fail originally,
> so that you have a connection marked as bad?
Going forward, perhaps it makes sense to reset %DBI_connect_bad
on a catalog reconfig.
Perusion -- Expert Interchange Consulting http://www.perusion.com/
phone +1.765.328.4479 <mike at perusion.com>
There's nothing sweeter than life nor more precious than time.
More information about the interchange-users