使用connector/j連線mysql資料庫，程式執行較長時間後就會報以下錯誤：
communications link failure，the last packet successfully received from the server was *** millisecond ago.the last packet successfully sent to the server was *** millisecond ago。
其中錯誤還會提示你修改wait_timeout或是使用connector/j的autoreconnect屬性避免該錯誤。
後來查了一些資料，才發現遇到這個問題的人還真不少，大部分都是使用連線池方式時才會出現這個問題，短連線應該很難出現這個問題。這個問題的原因：
mysql伺服器預設的「wait_timeout」是28800秒即8小時，意味著如果乙個連線的空閒時間超過8個小時，mysql將自動斷開該連線，而連線池卻認為該連線還是有效的(因為並未校驗連線的有效性)，當應用申請使用該連線時，就會導致上面的報錯。
1.按照錯誤的提示，可以在jdbc url中使用autoreconnect屬性，實際測試時使用了autoreconnect=true&failoverreadonly=false，不過並未起作用，使用的是5.1版本，可能真像網上所說的只對4之前的版本有效。
2.沒辦法，只能修改mysql的引數了，wait_timeout最大為31536000即1年，在my.cnf中加入：
[mysqld]
wait_timeout=31536000
interactive_timeout=31536000
重啟生效，需要同時修改這兩個引數。
SSH 連線超時解決辦法
高版本的 linux 自帶的openssh 在使用的時候，幾分鐘不操作的話就會自動斷開連線，這是出於安全的考慮，但是對於需要長時間使用的使用者來說很麻煩，每次都要重新連線。原因有多種 環境變數 tmout 引起,clientalivecountmax 和clientaliveinterval 設定問...
MongoDB 游標超時解決辦法
你在用 db.collection.find 的時候，它返回的不是所有的資料，而實際上是乙個 cursor 它的預設行為是 第一次向資料庫查詢 101 個文件，或 1 mb 的文件，取決於哪個條件先滿足 之後每次 cursor 中的文件用盡後，查詢 4 mb 的文件。另外，find 的預設行為是返回...
SSH 連線超時解決辦法
高版本的linux 自帶的openssh 在使用的時候，幾分鐘不操作的話就會自動斷開連線，這是出於安全的考慮，但是對於需要長時間使用的使用者來說很麻煩，每次都要重新連線。原因有多種,環境變數tmout 引起,clientalivecountmax 和clientaliveinterval 設定問題或...