#java #multithreading #kubernetes #ojdbc
Вопрос:
Я запускаю простой собственный код Java 8 для создания большого количества потоков. Эти потоки подключаются к базе данных через свое собственное выделенное соединение OJDBC. Поскольку база данных постоянно заполняется записями, потоки используют это выделенное соединение для выполнения различных задач в базе данных. каждый поток опрашивает базу данных через некоторое время, чтобы получить записи, затем обрабатывает их, а затем повторно опрашивает базу данных. соединение остается неизменным в течение всего срока службы потока. Вся эта настройка отлично работает, если я запускаю ее на простой виртуальной машине. Нет никаких замыканий соединения, но как только я перенес этот java-код в Kubernetes, начинают возникать проблемы . Через несколько раз каждый поток начнет выдавать следующее исключение
java.sql.SQLRecoverableException: Closed Connection
at oracle.jdbc.driver.PhysicalConnection.rollback(PhysicalConnection.java:3694)
Повторной инициализации соединения JDBC не происходит, поскольку потоки предполагают, что соединение выделено, и наша серверная система не закрывает соединение.
Это закрытие соединения происходит только в Kubernetes и случайным образом, поэтому мне интересно, есть ли какие-либо конкретные сетевые настройки, которые мне нужно сделать, чтобы выделенные соединения работали в Kubernetes ?
Комментарии:
1. Отправляете ли вы сообщения о сохранности TCP (или сообщения о сохранности на уровне протокола)? Если вы подключаетесь через сетку kube-прокси, возможно, из-за бездействия у вас истекает время ожидания iptables.
2. нет, нет сохранения жизни, отправляемого потоками, поэтому я предполагаю, что вы правы в том, что iptables запускают тайм-аут. Как я могу установить неограниченное время ожидания для всех исходящих подключений из модулей ?
Ответ №1:
Возвращаясь к комментариям, вы, вероятно, захотите включить сохраняемость TCP, но если это невозможно, посмотрите на net.netfilter.nf_conntrack_tcp_timeout_established
sysctl и аналогичные настройки conntrack. Вы также можете потенциально обойти сетку прокси-сервера, используя вместо этого службу безголового режима, хотя это, скорее всего, повлияет на ваш процесс отработки отказа, поэтому обязательно тщательно проверьте это.
Комментарии:
1. Спасибо, что объяснили, я проверил настройки, и в настоящее время он установлен на
net.netfilter.nf_conntrack_tcp_timeout_established = 86400
24 часа. Еще одна вещь, когда возникает эта проблема, я вижу много соединений в состоянии TIME_WAIT в списке conntrack, поэтому вы предлагаете сократить это время ?