|
|
|
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
|
|||
|---|---|---|---|
|
#18+
не знаю в какую ветку лучше - сюда или в mysql, но поскольку проблема больше похожа на проблему настройки коннектора, то наверное сюда. Столкнулся со следующей проблемой. Есть приложение на java, которое открывает коннекшен и периодически делает через него селекты. Инсерты и апдейты через это соединение не делаются, соответственно, никаких транзакций нет. При этом, когда селекты делаются, то их делается много, поэтому кажый раз создавать для каждого селекта коннекшен - это не выход. Так же, неизвестно, через сколько времени после текущего селекта будет следующий - то ли десятки мс, то ли часы. Если нет запросов к базе около 20 минут, а потом делаешь select, то бросается такой экзепшен: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure The last packet successfully received from the server was 1 268 300 milliseconds ago. The last packet sent successfully to the server was 1 milliseconds ago. При этом, следующие запросы через этот же PreparedStatement или Statement отрабатывает нормально. Система - ubuntu 12.04 lts x64, коннектор юзается от mysql, а не от mariadb (коннектор от mariadb в 2 раза медленей на больших селектах) Переменные mysql: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Как видно из переменных, wait_timeout равно 28800сек, что составляет 8 часов, против 20 минут которые есть по факту. Это аргумент в пользу того, что на стороне mysql все ок, а проблема с коннектором. Cтрока, которой создается коннекшен такая: jdbc:mysql://localhost:3306/archive_db?user=u&password=pass&autoReconnect=true&failOverReadOnly=false&maxReconnects=10 Вопрос: задача-минимум: обеспечить чтобы хотя бы обещанные 28800сек оно работало без подобного поведения задача-максимум: вообще избежать такого поведения, не используя классов-оберток вокруг mysql-евского Statement, которые бы перехватывали CommunicationsException (это ж надо перехватывать из пакета com, что не есть правильно, а перехватить родителя SQLRecoverableException это тоже может быть не правильно) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2014, 20:25 |
|
||
|
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
|
|||
|---|---|---|---|
|
#18+
Исключение обрабатывают там, где оно возникает. А это - ваш код. И совершенно наплевать кем оно было выброшено. Если вы не можете управлять тем, как пул закрывает/валидирует соединения - надо принять как факт, что пул может выдать "дефектное" подключение и доработать ваш код. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2014, 20:30 |
|
||
|
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, Не согласен, исключение - это внеплановая ситуация. А у меня 20 минут неактивности - по плану. Поэтому планового искючения по причине "прошло больше 20 минут" быть не должно. Может пул можно как-то донастроить? Если идти путем перехвата исключений. Бросается исключение из пакета com. Использовать исключения из пакета com не рекомендуется. Как правильно сделать, если база может быть и не mysql? Ближайший наследник это SQLRecoverableException. Но означает ли это что в других типах баз (например оракл) перехват SQLRecoverableException не приведет нежелательному поведению? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2014, 21:16 |
|
||
|
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
|
|||
|---|---|---|---|
|
#18+
chabapokЕсли идти путем перехвата исключений. Бросается исключение из пакета com. Использовать исключения из пакета com не рекомендуетсяЕщё раз: пакет - всего лишь способ организации классов, мимикрирующий файловую систему. Нет у com.* никакого сакрального свойства и смысла. Есть, всего лишь, рекомендация не использовать классы Java SE/EE вне документированной иерархии. Классы (пула) MySQL частью Java SE/EE - не являются. У них есть своя документированная иерархия, которая никак не соотносится со всем остальным миром. (До)настройку (пула) делают в соответствии с документацией, экспериментально проверяя неясные или/и сомнительные моменты. Ну или делают обработку возможных ошибок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2014, 21:26 |
|
||
|
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
|
|||
|---|---|---|---|
|
#18+
Ну у меня не пул, а обычный jdbc коннектор. и эти долбаные 20 минут в него где-то вбиты. Суть в том, что меня такое поведение устраивает, но претензии к числу 20 минут -- хочется больше, а такой настройки у jdbc вроде как нету. Может в com и нет сакрального смысла, но в данном конкретном случае это плохая практика. Другая база бросит в той же ситуации исключение не com.mysql, и привет. И вообще, хотя в com сакрального мысла нет, но есть смысл его не использовать, для будущей обратной совместимости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2014, 22:03 |
|
||
|
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
|
|||
|---|---|---|---|
|
#18+
ОС может соединения рвать, у меня такое было ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2014, 04:33 |
|
||
|
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
|
|||
|---|---|---|---|
|
#18+
блин, да делай селект мелкий раз в 10 минут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2014, 05:05 |
|
||
|
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
|
|||
|---|---|---|---|
|
#18+
chabapokМожет в com и нет сакрального смысла, но в данном конкретном случае это плохая практика. Другая база бросит в той же ситуации исключение не com.mysql, и приветДа мопжевашуять ... Будете работать с другой базой - будете разбираться с другой проблемой. Если таковая проблема вообще возникнет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2014, 06:10 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38682900&tid=2126981]: |
0ms |
get settings: |
6ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
176ms |
get topic data: |
8ms |
get forum data: |
3ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 209ms |
| total: | 464ms |

| 0 / 0 |
