Skip to main content
Inspiring
January 4, 2011
Answered

Coldfusion 9 MySQL communications link failure

  • January 4, 2011
  • 4 replies
  • 24647 views

've just installed Coldfusion 9, and everything is now working fine and it's connected to my MySQL databse via the Coldfusion Administrator as a datasrouce, but I get this error occuring infrequently, maybe 5 - 10 times a day. I don't know how to recreate it, and if you get it and refresh the page it goes away.

Error Executing Database Query. Communications link failure Last packet sent to the server was 0 ms ago

The error is being caught by coldfusion as it's displaying a user friendly message and emailing me the problem.

Almost all of the time the pages load and work fine, and this problem has only happened since going from CFMX7 to CF9, both using MySQL.

The MySQL version I am using is "5.0.77"

I've tried localhost and 127.0.0.1 as the host in the datasource, it makes no difference.

Does anyone have any idea what this is and how to fix it? I've seen some similar posts for Java but I don't see how to translate the fix across into Coldfusion?

And could it be a MySQL or Apache problem anyway?

    This topic has been closed for replies.
    Correct answer StevenErat

    PeteComcar wrote:

    I didn't think you were being malicious, I just don't know what packet sniffing is... that's all!

    Anyway, before reading this post I actually UNCHECKED maintain connections.

    The reason being I got a different error at 11am yesterday

    "The server encountered an internal error and was unable to complete your request. Application server is busy. Either there are too many concurrent requests or the server is still starting up"

    I checked the error log and it was a JRun error, did some Googling and found some suggestions to UNCHECK maintain connections, so I did that, and it fixed both errors - so it was indeed to do with the CF9 settings.

    So sorry to contradict you BKBK but I'm leaving maintain connections unchecked.

    I can understand. I too have now googled up on the matter. It appears this is indeed a bug in ColdFusion 9.

    Not surprising. Seach for MySQL in the ColdFusion Bugbase, and you will find that there have been connection issues between ColdFusion 9 and versions of MySQL newer than 5.0.x right from the beginning.

    It is therefore not a coincidence that unchecking 'Maintain Connections' seems to work. It confirms there is a connection issue.

    That setting has to do with connection pooling. When you check it, ColdFusion reuses a connection from a pool of connection objects for numerous queries to the database server. This reuse of course means sparing CPU resources, hence efficiency. Unchecking the setting compels ColdFusion to create a new connection for each query. You wouldn't want that, if your application is data-intensive.

    I have gathered from the reactions on the web that the driver that ships with ColdFusion 8 appears to work well with the setting "Maintain Connections". That driver is mysql-connector-java-commercial-5.0.5-bin.jar. The newer driver that ships with ColdFusion 9 is mysql-connector-java-commercial-5.1.11-bin.jar. This brings me to my suggestion for a test. It goes without saying, you should do the test on a test server, not in production!

    Stop ColdFusion 9. Copy mysql-connector-java-commercial-5.0.5-bin.jar to the lib directory (if you don't already have it there). Remove all other drivers of type mysql-connector-java-commercial-x.x.x-bin.jar from the lib directory, and store them in a back-up location out of the lib directory.

    Restart ColdFusion 9. Choose MySQL 4/5 and check the setting to Maintain Connections. Any more communication failure?


    The Maintain Connections setting means that after a db connection is created

    for a given database, that connection will be used for the current query and

    then kept open in a connection pool so that they can be reused for later

    queries. The reason is that opening a connection is an expensive, time

    consuming operation, and its more efficient to only have to authenticate

    once. When this setting is disabled, for every page request accessing a

    given database, a new database connection will be created, the db

    authentication will occur, the query/queries on the request will happen,

    then the db connection will be closed.

    When you maintain connections you have a pool of db connections that exist

    for an extended period, being frequently reused with additional requests.

    If the connections are idle for a period greater than the Inactive Timeout

    setting in the datasource definition, then those connections are closed and

    the pool size is reduced. Also, if a request checks out a connection from

    the pool, attempts to use it for a query for some request, then if that db

    connection produces a db error then that is another situation where the db

    connection will be closed and removed from the pool.

    It has been known to happen that when you are pooling datasource connections

    like this that its possible that the TCP connection to the database has been

    interrupted for some reason, and when the connection is checked out for use

    on a page request you will get some type of "communication" error. The

    actual error message will vary depending on the database.

    If unchecking Maintain Connections resolves this MySQL Communication Link

    Failure issue for you, then you are better off re-checking it AND adding a

    validation query. ColdFusion 8.0 introduced a field in the dsn definition

    for Validation Query. It works this way: When a database connection is

    first created AND every subsequent time that connection is checked back out

    from the pool, the validation query will run BEFORE any queries for the page

    request. If the validation query fails, your page request will never see

    the error because ColdFusion will throw away that db connection and get

    another connection from the db connection pool. It will then run the

    validation query for that connection too. If that one errors, ColdFusion

    will continue closing the bad connections and checking out other connections

    until there are no connections left in the connection pool. If it actually

    got that far (meaning every connection in the pool turned out to be bad)

    then ColdFusion will then create a NEW db connection and use that one, and

    it will run the validation query on that too. All of this happens before

    your request runs to guarantee that your request gets a good db connection

    from the start.

    A good validation query is something is that is highly efficient so that db

    isn't really taxed by having to run it. For MySQL you could use: Select 1

    That's it. Enter that into the validation query field for the datasource

    and keep Maintain Connections checked to improve efficiency with connection

    pooling.

    Make sense?

    4 replies

    Inspiring
    January 13, 2011

    Right, I've not had the errors occuring for 2 days now,

    the day before last I had "Maintain Connections" UNchecked,

    yesterday I had "Maintain Connections" checked and was using a validation query.

    Thank you both for your help and advice, I am now much more knowledgeable when it comes to Coldfusion Datasources.

    The problem is obviously still there in the background, and this is just a work around using the validation query, I will continue to apply MySQL and Coldfusion 9 updates and run another datasource without the validation query to see if the problem stops occuring with future updates.

    However as the error is so infrequent, I agree with Steven that it's a suitable workaround, especially as I've got other work to do and the front end user is none the wiser.

    I will also investigate further with the error logs and see if I can find out any more information, but I'm not promising any speedy updates on the matter.

    As a final point, I've got this question on StackOverflow.com and I'll have to mark the question as answered by myself and refer to this post here, unless either of you want to respond to the post so I can give you the credit you're due.

    http://stackoverflow.com/questions/4500414/coldfusion-9-mysql-communications-link-failure

    BKBK
    Community Expert
    January 13, 2011

    PeteComcar,

    You get no more communication failure. You have Maintain Connections going, too! What more could you want? Hats off to Steven!

    April 11, 2011

    I've read through this and made changes based on these posts, but still have a few questions relating to a DSN 'failure'

    http://forums.adobe.com/thread/836689

    Thanks so muc if you can help explain/resolve!

    BKBK
    Community Expert
    January 8, 2011

    The fact that it occurs intermittently makes me think it could be caused by a middle-man application -- firewall, proxy, antivirus, that sort of thing.

    Inspiring
    January 7, 2011

    Ok I added an "other" database type, and it's doing the same thing, works most of the time but occasional "communications link failure" messages coming in.

    I used the latest Connector/J 5.1.14, on MySQL 5.0.77.

    I think my next move is to try to update MySQL to 5.1, and if that still fails then 5.5.8.

    Inspiring
    January 8, 2011

    Have you thought about the possibility of a network issue? Yes it is over

    local host, but I'd be curious if you could reproduce it when MySQL is on

    another host so that you could use a packet sniffer like Wireshark to see if

    packets are getting refused or reset or dropped. But if you're seeing this

    in production then you probably won't be able to do that.

    How about enabling MySQL logging. Its pretty simple to enable, but logs

    could grow quite large before you see it. The point is that you can pair up

    events on the CF side with events on the MySQL side to see what's going on

    there at the same time.

    I'll give it some more thought.

    BKBK
    Community Expert
    January 12, 2011

    A database connection in the connection pool maintains an TCP connection to

    the database. If the connection is idle for a little while and something

    happens to break that previously established TCP connection, then the next

    query to try to use that db conn after checking it out will encounter some

    type of communication error (I think I recall that Oracle would report a

    "Net 8 Protocol Error" or similar) This is where the validation query is

    helpful because it tests for bad or "stale" connections before letting the

    request use it.

    There are a range of things that can interrupt or break the TCP connection

    from under a DB connection that has been idle. A problematic router, a db

    that was restarted, and other more subtle reasons. Some even over

    localhost. I think there's a good chance validation query will prevent the

    application from encountering this type of communication link error.


    StevenErat wrote:

    A database connection in the connection pool maintains an TCP connection to

    the database.  If the connection is idle for a little while and something

    happens to break that previously established TCP connection, then the next

    query to try to use that db conn after checking it out will encounter some

    type of communication error (I think I recall that Oracle would report a

    "Net 8 Protocol Error" or similar)   This is where the validation query is

    helpful because it tests for bad or "stale" connections before letting the

    request use it.

    There are a range of things that can interrupt or break the TCP connection

    from under a DB connection that has been idle.  A problematic router, a db

    that was restarted, and other more subtle reasons.  Some even over

    localhost.  I think there's a good chance validation query will prevent the

    application from encountering this type of communication link error.

    You certainly have much more experience in the matter than I do. I hasten to add that I am just trying to figure this out on paper, as it were.

    The validation query is like me calling out to the waiter to make an order.  Calling him is a test to see whether I can get his attention. What if a communication problem prevents him from hearing me? Then he wont be able to transmit my order to the kitchen, let alone bring me the grub.

    Same goes for the validation query. What if the same persistent communication failure prevents the validation query from being transmitted to the database for execution? Then ColdFusion will know the connection is bad. My point is, that will be that and we will be back to where we started.

    Inspiring
    January 4, 2011

    Since the driver for MySQL 5 wasn't built into ColdFusion MX 7, but does

    come with ColdFusion 9, what driver were you using with CFMX7? You could

    try to configure that same driver as type "Other" in the CF9 CFAdmin, then

    name it the same as your production datasource name. Does that make a

    difference?

    ColdFusion 8 was the first version of CF to ship the JDBC driver for MySQL

    4/5 (I'm actually the one on the Adobe CF team that added the driver and

    updated CF Admin to show the driver option). The driver we used was the

    mysql commercial driver, and with CFMX 7 you may have been using the MySQL

    community driver.

    I wrote this technote a few years back. You could use it still in CF9 to

    add a different driver: http://kb2.adobe.com/cps/191/tn_19170.html Its

    possible that because the driver class name is probably the same in the

    custom driver as it is in the built-in driver (com.mysql.jdbc.Driver) you

    may have to stop ColdFusion first, then move the existing

    ColdFusion/lib/mysql-connector-java-commercial-5.1.11-bin.jar to a safe,

    temporary location while you test your custom MySQL driver.

    Inspiring
    January 5, 2011

    I can't remember now, but I think it was just a MySQL 3/4 driver from the drop down at the top.

    I remember my old local windows machine and new Ubuntu machine both have a driver that I had to download and set up as "other", but the old live machine used the MySQL driver from the drop down, so I just did the same thing for the new live one, but noticed it had changed to MySQL 4/5.

    I'll try setting it up as an "other"... I should have thought of that myself. I'll have to wait till we're out of peak times now, I'll try that later tonight and update the ticket later.