Я запускаю приложение spring boot с помощью docker swarm и использую postgres для базы данных. Когда я запускаю их оба как службу docker, подключение к базе данных происходит последовательно и случайным образом (как вы можете видеть на временной метке), как указано в журнале:
2017-10-26T17:14:15.200415747Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: не удалось получить данные от клиента: соединение сброшено одноранговым узлом
2017-10-26T17:43:36.481718562Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: не удалось получить данные от клиента: соединение сброшено одноранговым узлом
2017-10-26T17:43:56.954152654Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: не удалось получить данные от клиента: соединение сброшено одноранговым узлом
2017-10-26T17:44:17.434171472Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: не удалось получить данные от клиента: соединение сброшено одноранговым узлом
2017-10-26T17:49:04.154174253Z app-db.1.1ayo6h8ro1og@scw-c2964a | LOG: не удалось получить данные от клиента: соединение сброшено одноранговым узлом
Я не мог понять или обнаружить причину этого. Я был бы признателен за любые идеи.
редактировать:
мы поняли, что при тестировании приложения оно также выдает ошибку, подобную этой:
Исключение SQLTransientConnectionException: HikariPool-1 - Соединение недоступно, время ожидания запроса истекло через 937517 мс
Спасибо.
У меня такая же ошибка при развертывании Docker Swarm stack приложения Spring Boot и PostgreSQL. После борьбы с этим около недели я выяснил, что проблема заключалась в том, что брандмауэр отключал соединения между контейнерами из-за бездействия. Быстрый ответ, запустите следующий cmd на компьютере с Linux:
sudo sysctl -w \net.ipv4.tcp_keepalive_time=600 \net.ipv4.tcp_keepalive_intvl=60 \net.ipv4.tcp_keepalive_probes=3
Кроме того, я включил следующие свойства пула подключений tomcat:
tomcat: max-active: 10 initial-size: 5 max-idle: 8 min-idle: 5 test-on-borrow: true test-while-idle: true test-on-return: false test-on-connect: true validation-query: SELECT 1 validation-interval: 30000 max-wait: 30000 min-evictable-idle-time-millis: 60000 time-between-eviction-runs-millis: 5000 remove-abandoned: true remove-abandoned-timeout: 60
Решение пришло из этого поста в блоге: РАБОТА С ИСКЛЮЧЕНИЯМИ NODENOTAVAILABLE В ELASTICSEARCH
Есть еще один способ предотвратить закрытие незанятого соединения. Проблема связана с обнаружением службы swarm по умолчанию, которая закрывает незанятое соединение через 15 минут.
Явно указано, что dnsrr режим конечной точки решает проблему, например:
version: '3.3'services: foo-service: image: example/foo-service:latest hostname: foo-service networks: - foo_network deploy: endpoint_mode: dnsrr # ...networks: foo_network: external: true driver: overlay