On 10/22/2012 4:41 PM, David F. Skoll wrote:
On Mon, 22 Oct 2012 16:32:24 -0400
"Kevin A. McGrail" <[email protected]> wrote:
Anyone have any guidance on settings for -P and -X in order to
maintain persistent DB connections?
Yeah, don't. Because it won't work (as you no doubt discovered. :))
Thanks David. In a way, this was more helpful than you might imagine
because my analysis was leading towards certain slaves never running
ticks but this makes it definitive without me researching.
The logical place to do that
would be right at the beginning of filter_sender, filter_recipient,
filter_begin, etc.... whichever callbacks you care about.
For me, at least, with a 0.33% failure rate being rather low, rather
than adding ping a whole bunch of times at each callback that might use
a DB call, I've changed my centralized query function to try connecting
if the query fails with what looks like a timeout failure. I also added
some logic so it tries only one more time.
Beyond that, I haven't figured out why I think this is more elegant than
your logic, though so any input greatly appreciated.
Overall though, knowing that this "bandaid" is needed because you can't
really guarantee a tick will maintain a persistent DB connection makes
me feel a lot better about using such a bandaid.
(Also, SQL client timeouts are totally evil. Don't use them. If your
DB can't handle lots of connections, use a connection pooler.)
Thanks. That makes sense.
Regards,
KAM
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
