Выследить java.net.SocketException: нет свободного места в буфере - PullRequest
Новая
       14

Выследить java.net.SocketException: нет свободного места в буфере

8 голосов
/ 04 августа 2009

Привет, у меня очень неприятная проблема с: java.net.SocketException: нет свободного места в буфере (достигнуто максимальное количество соединений?) Это клиент-серверное приложение. Клиент - Windows XP SP2 32b, с двумя сетевыми картами Core Duo. Java 1.6. u7. Приложение имеет пару сокетов сервера, открытых для локальной связи, и пару сокетов клиента для rmi к серверу jboss.

Через пару часов / дней! Я не могу открыть новый клиентский сокет для связи с сервером. Серверные сокеты все еще работают.

Windows netstat показывает что-то от 130 до 150 соединений. При попытке вручную я исчерпал буфер после ~ 3500 соединений!

Я пытался:

проверяйте каждую используемую нами розетку, чтобы она также закрывалась. запустить netstat в фоновом режиме для отслеживания открытых соединений запустить проверку на вирусы, чтобы найти любую вредоносную программу обновление Java до 1.6 u16 отключить второй сетевой интерфейс
После перезапуска Java я могу открыть новое соединение.

Всего исключений: 

cause:javax.naming.CommunicationException: Failed to connect to server IP:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server IP:1099 [Roo
t exception is java.net.SocketException: No buffer space available (maximum connections reached?): JVM_Bind]]
2009-08-03 09:13:18,968 DEBUG [Thread-9] - stack trace:
2009-08-03 09:13:18,968 DEBUG [Thread-9] - org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1562)
2009-08-03 09:13:18,968 DEBUG [Thread-9] - org.jnp.interfaces.NamingContext.lookup(NamingContext.java:634)
2009-08-03 09:13:18,968 DEBUG [Thread-9] - org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
2009-08-03 09:13:18,968 DEBUG [Thread-9] - javax.naming.InitialContext.lookup(Unknown Source)

- отредактированный
Мы наконец-то столкнулись с проблемой неисправности сервера snmp. Я написал свои заметки в комментариях ниже. Спасибо за помощь.

Ответы [ 3 ]

3 голосов
/ 04 августа 2009

Звучит так, как будто вы как-то пропускаете сокеты в своем приложении.

  • Убедитесь, что ваш код всегда закрывается Розетки это открывает ... даже в событие какого-то исключения; то есть сделать закрыть в блоке finally.
  • Если ваш код использует URL-соединения, убедитесь, что они отключены.
  • Я не эксперт, но должен ли ваш код закрывать объект InitialContext?
1 голос
/ 25 августа 2009

То, что мы пытались (и успешно) убить проблему. ДЖАВА - проверьте снова каждый сокет, который мы использовали, при необходимости зарегистрируйте их в каком-то специальном классе
- предоставить SocketFactory и ServerSocketFactory для каждого класса, который открывает сам сокет (например, коннекторы jboss)
- проверить открытые файлы, окончательно закрыть их
- URL также открывает соединение, но если после этого вы запрашиваете поток, соединение закрывается вместе с потоком (спасибо Стивену).

OS
- использовать разные java (1.5, 1.6, 1.7)
- установить новые драйверы
- используйте netstat и следите за трафиком в фоновом режиме (используя скрипты, да, win xp может делать скрипты довольно хорошо). При необходимости используйте расширенный анализатор пакетов (wire shark?).
- win xp имеет лимит для одновременных подключений, проверьте их (Google) тоже
- проверять снова и снова на наличие вирусов и вредоносных программ (даже в частной сети!)

0 голосов
/ 26 февраля 2014

Прочитав совет, предложенный в этой ссылке ! Мне удалось определить, что я слишком часто использовал isDisplayed () за слишком короткое время. Поэтому я поместил 5 миллисекундное ожидание между вызовами isDisplayed. Это исправило мою проблему Исключения Сокета. 

    for (final WebElement person: persons){
        if (person.isDisplayed()){
            dosomething;
            sleep 5 milliseconds
        }
    }

Как указано в ссылке, вы должны вставить try catch на тот случай, если это ожидание не достаточно продолжительное.

...