oracle thin соединение jdbc, получающее «сброс соединения» после неактивности

Question

У меня есть новый сервер приложений tomcat, работающий на tomcat 6, java 6 (openjdk), centos 6.2. Сервер представляет собой виртуальную машину, работающую под qemu-kvm на хосте centos 6.2. Хост и гость являются 64-битными.

У меня есть случай, когда соединение открывается (из пула соединений), после чего происходит "длительное вычисление" в течение примерно 4 часов, в течение которого соединение не используется. Наконец, выдается «commit», и сервер выдает исключение «сброс соединения», а именно:

Caused by: java.net.SocketException: Connection reset
    at java.net.SocketInputStream.read(SocketInputStream.java:185)
    at oracle.net.ns.Packet.receive(Packet.java:282)
    at oracle.net.ns.DataPacket.receive(DataPacket.java:103)
    at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:230)
    at oracle.net.ns.NetInputStream.read(NetInputStream.java:175)
    at oracle.net.ns.NetInputStream.read(NetInputStream.java:100)
    at oracle.net.ns.NetInputStream.read(NetInputStream.java:85)
    at oracle.jdbc.driver.T4CSocketInputStreamWrapper.readNextPacket(T4CSocketInputStreamWrapper.java:122)
    at oracle.jdbc.driver.T4CSocketInputStreamWrapper.read(T4CSocketInputStreamWrapper.java:78)
    at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1179)
    at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1155)
    at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:279)
    at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:186)
    at oracle.jdbc.driver.T4C7Ocommoncall.doOCOMMIT(T4C7Ocommoncall.java:75)
    at oracle.jdbc.driver.T4CConnection.doCommit(T4CConnection.java:558)

Сервер базы данных и клиент находятся в одной подсети, за исключением того, что сервер является реальным физическим хостом, и, очевидно, сервер приложений является гостем, работающим на физическом компьютере в той же подсети.

Хост использовал "мостовую" сеть.

Это может быть не проблема программного обеспечения, а проблема конфигурации Linux (iptables?), Но я действительно не знаю.

Answer 1

Я сталкивался с этим пару раз.Почти всегда вызвано сетевым таймаутом (балансировщик нагрузки или брандмауэр).Но вы четко упомянули, что ваши серверы находятся в одной подсети, поэтому не совсем уверены, что происходит.Так как вы подозреваете iptables, можете ли вы отключить его, запустить тест и посмотреть, работает ли он (слишком просто, да :)

Независимо от того, предполагается ли, что вы подключаетесь к базе данных Oracle, следующая настройка помогает

http://raibledesigns.com/rd/entry/tomcat_oracle_connectivity_problems

Если вы используете другой дБ (скажем, mysql), настройка может быть другой, но логика та же.Установите значение keepalive, чтобы соединение не находилось слишком долго бездействующим.Таким образом, программное обеспечение firewal / load loadr / iptables не прекратит его.

Answer 2

@ пользователь обращается к хорошему обходному пути, настроив «SQLNET.EXPIRE_TIME = 10» в sqlnet.ora.

Однако этот обходной путь применим только в том случае, если в вашем приложении используется толстый драйвер OCI (jdbc: oci), а не тонкий (jdbc: thin).

В Linux есть программный брандмауэр, т.е. iptables, который может разорвать простое сетевое соединение, поэтому даже если вы находитесь в одной подсети, у вас есть программный брандмауэр iptables. Это включено по умолчанию во всех современных Linux, и администратор Linux может отключить его.

По умолчанию iptables Linux не сбрасывает бездействующие соединения TCP / IP (jdbc относится к протоколу TCP / IP), поэтому администратор Linux должен настроить iptables для этого. Ниже приведено подробное объяснение для любого читателя, которому интересно узнать больше:

http://www.digitage.co.uk/digitage/software/linux-security/cutter

Бизнес-пользователи, команда безопасности или архитектор часто предлагают администратору сети / ОС прервать неактивное соединение с помощью брандмауэра, а также маршрутизатора. Это всегда «рекомендация» в сообществе по борьбе со взломом, но она не обсуждается должным образом и вызывает нестабильность приложения. В конце концов, вы должны обсудить с командой, чтобы найти баланс

Answer 3

Как вы можете видеть в этом сообщении на форумах Oracle, это может иметь более одной проблемы / решения.

• Проверьте правильность версии вашего драйвера JDBC
• Проверьте переменную среды ORACLE_HOME
• попробуйте добавить аргумент -Djava.security.egd=file:///dev/urandom
• Ваша логика использует одноэлементное соединение? В посте это тоже упоминается

Надеюсь, это поможет вам.