http://coldfusion.com logo
Join Slack
Powered by
As longs as I've been working in CF, after <som...
# cfml-general
d
As longs as I've been working in CF, after <some event that happens sometimes>, CF throws this: "[Macromedia][SQLServer JDBC Driver]Connection reset by peer: socket write error". I think the trigger is something having restarted, probably CF. It's stable during normal operation, so this isn't super important, it just emails us devs, so I'm wondering if there's a way to avoid it. Ring any bells?
b
That's a pretty generic error-- usually means the underlying TCP connection for the datasource connection was interrupted or forcibly closed (such as the DB getting rebooted)
Always when dealing with a JDBC error, scroll all the way to the bottom of the stack trace to look for a 
CAUSED BY
section
Also not, if all the DB connections are reset, you'll get this error the next time CF tries to use each one, until they are all recycled. Used a validation query to prevent this by testing each pooled connection before using it,
👍🏼 1
👍 1
@Dave Merrill
d
Thanks Brad. Short of running a validation query before every attempt to contact the db, or manually doing it when we have reason to think the cf server may have restarted, how can we make practical use of this strategy?
b
Well, it depends on what the root cause really is
but if it's just a broken DB connection, then the validation query really is the only fix
b
try-catch comes to mind...
b
In Adobe CF you actually put in a SQL query-- I use
Copy code
SELECT 1
just to hit the DB.
In Lucee, "validate" is just a checkbox and it uses an underlying JDBC method to validate the connection
Unless you have some sort of massive load, I've never see the overhead of validation to be noticeable.
And yes, try/catch could work, but that sounds pretty terrible to have to wrap every query in your app with retry logic. And any "internal" use of a datasource such as DB-stored client variables wouldn't be helped there
b
"SELECT 1" seems like a good solution... thanks @bdw429s I don't think I'd have thought of that...
Not before building a very complicated try-catch loop... 😉
😆 2
b
lol, and to be clear, that validation query goes in the CF administrator when editing the datasource. It's something the CF engine does for you
d
Our higher-level error handling does catch these, that's how us devs get emailed. I was just wondering if there was a more proactive way to avoid those emails after a cf restart.
b
Well, you could put an if statement in your error handling to ignore them, lol
But if they're happening, that still means your users are getting an error page
d
When does the validation query in admin run? I thought only when you saved the datasource.
b
No, you're thinking of the "verify" button
b
we have a pretty good Error Log - we just ignore that... 😉
😂 1
b
validation query runs every time a pooled datasource connection is taken from the pool for use. Which for Adobe CF, is once at the start of the CF page (as it re-uses the same one for the entire request)
d
us too, I was just wondering if there was a magic trick to keep it from happening in the first place, guessing no.
b
No, that is the nature of pooled datasource connections
Java holds onto the connection object and assumes the underlying TCP connection is still open, but it doesn't really know until it uses it
d
Makes sense. Blessed be the things that go bump in the night that we've seen before, understand, and do no harm :)
2 Views
Open in Slack
PreviousNext
Powered by