查找 java.net.SocketException:没有可用的缓冲区空间

发布于 2024-07-29 12:26:53 字数 1444 浏览 10 评论 0原文

嗨,我有一个非常丑陋的问题: java.net.SocketException:没有可用的缓冲区空间(已达到最大连接数?) 它是客户端-服务器应用程序。 客户端是Windows XP SP2 32b,有两个网卡核心双核。 Java 1.6。 u7。 应用程序有几个打开的服务器套接字用于本地通信,以及几个用于 rmi 到 jboss 服务器的客户端套接字。

几个小时/几天后! 我无法打开任何新的客户端套接字来与服务器进行通信。 服务器套接字仍然有效。

Windows netstat 显示从 130 到 150 个连接。 当手动尝试时,我在大约 3500 个连接后耗尽了缓冲区!

我试过:

  • 检查我们使用的每个套接字并关闭它。
  • 在后台运行 netstat 以监视打开的连接
  • 运行病毒扫描以发现任何恶意软件
  • 将 java 更新到 1.6 u16
  • 禁用第二个网络接口

  • Once java is restarted I am able to open new connection.

    整个异常:

    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)
    

    --edited
    我们终于解决了 snmp 服务器故障的问题。 我在下面的评论中写下了我的笔记。 感谢您的帮助。

    Hi I have very ugly problem with:
    java.net.SocketException: No buffer space available (maximum connections reached?)
    It is client-server app. Client is Windows XP SP2 32b, with two net cards core duo. Java 1.6.
    u7.
    Application have couple server socket open for local communication and couple of client socket for rmi to jboss server.

    After couple of hours/days! i am unable to open any new client socket to do communication to server. Server sockets still works.

    Windows netstat shows something from 130 to 150 connection. When manually trying I exhausted buffer after ~3500 connections!

    I tried:

  • check every socket we use that we also close it.
  • run netstat at background to monitor opened connections
  • run virus scan to found any malware
  • update java to 1.6 u16
  • disable second network interface
  • Once java is restarted I am able to open new connection.

    Whole Exception:

    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)
    

    --edited
    We finally hit the problem with malfunctioning snmp server. I wrote my notes in comment bellow. Thanks for help.

    如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

    扫码二维码加入Web技术交流群

    发布评论

    需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

    评论(3

    穿越时光隧道 2024-08-05 12:26:53

    听起来确实像是您在应用程序中以某种方式泄漏了套接字。

    • 检查您的代码是否始终关闭
      它打开的套接字...即使在
      发生某种异常情况; 即做
      finally 块中关闭。
    • 如果您的代码使用 URL 连接,
      确保它们已断开连接。
    • 我不是专家,但是您的代码应该关闭其 InitialContext 对象吗?

    It certainly sounds like you are leaking Sockets somehow in your app.

    • Check that your code always closes
      the Sockets it opens ... even in the
      event of some exception; i.e. do the
      close in a finally block.
    • If your code uses URL connections,
      make sure that they get disconnected.
    • I'm not an expert, but should your code close its InitialContext object?
    红焚 2024-08-05 12:26:53

    我们尝试(并成功)解决了这个问题。
    爪哇
    - 再次检查我们使用的每个套接字,如果需要的话将它们注册到一些特殊的类中
    - 为每个打开套接字本身的类提供SocketFactory和ServerSocketFactory(例如jboss连接器)
    - 检查打开的文件,最后关闭它们
    - URL 也会打开连接,但如果您在此之后请求流,连接将与流一起关闭(感谢斯蒂芬)。

    操作系统
    - 使用不同的java(1.5、1.6、1.7)
    - 安装新驱动程序
    - 使用netstat并监控后台流量(使用脚本,是的win xp可以很好地执行脚本)。 如果需要,请使用高级数据包嗅探器(wire shark?)。
    - win xp 对并发连接有限制,也检查一下(google)
    - 反复检查病毒和恶意软件(即使在专用网络上!)

    What we tried (and successfully) kill the problem.
    JAVA
    - check again every socket we used, register them in some special class if needed
    - provide SocketFactory and ServerSocketFactory for every class which open socket itself (for example jboss Connectors)
    - check opened files, close them in finally
    - URL opens connection too, but if you ask for stream after that, connection is closed together with stream (thanks Stephen).

    OS
    - use different java (1.5, 1.6, 1.7)
    - install new drivers
    - use netstat and monitor traffic on background (using scripts, yes win xp can do the scripts pretty nicely). Use advanced packet sniffers (wire shark?) if needed.
    - win xp have limit for concurrent connections, check them (google) too
    - check again and again for virus and mallware (even on private network!)

    叫嚣ゝ 2024-08-05 12:26:53

    阅读此链接! 我能够确定我在太短的时间内过于频繁地使用 isDisplayed() 。 因此,我在调用 isDisplayed 之间设置了 5 毫秒的等待时间。 这解决了我的套接字异常问题。

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

    如链接中所述,您应该插入一个 try catch 以防等待时间不够长。

    After reading the advice offered in this link! I was able to determine that I was using isDisplayed() way too often in too short of a time. Therefore, I placed a 5 millisecond wait between calls to isDisplayed. This fixed my Socket Exception issue.

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

    As stated in the link you should insert a try catch just in case this wait is not long enough.

    ~没有更多了~
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文