weblogic集群 启动受管服务器时java.io.IOException: Invalid argument

在weblogic 集群环境中,启动受管服务器时报错

Multicast socket receive error: java.net.SocketException: Socket closed

……

java.io.IOException: Invalid argument

        at java.net.PlainDatagramSocketImpl.send(Native Method)

        at java.net.DatagramSocket.send(DatagramSocket.java:698)

        at weblogic.cluster.MulticastFragmentSocket.sendThrottled(MulticastFragmentSocket.java:206)

        at weblogic.cluster.MulticastFragmentSocket.send(MulticastFragmentSocket.java:158)

        at weblogic.cluster.FragmentSocketWrapper.send(FragmentSocketWrapper.java:91)

        Truncated. see log file for complete stacktrace

 

解决办法:

打开/home/weblogic/Oracle/Middleware/user_projects/domains/base_domain/bin下的startManagedWebLogic.sh文件,找到

JAVA_OPTIONS="-Dweblogic.security.SSL.trustedCAKeyStore="/home/weblogic/Oracle/Middleware/wlserver_10.3/server/lib/cacerts" ${JAVA_OPTIONS}"

修改为

JAVA_OPTIONS="-Dweblogic.security.SSL.trustedCAKeyStore="/home/weblogic/Oracle/Middleware/wlserver_10.3/server/lib/cacerts" ${JAVA_OPTIONS} -Djava.net.preferIPv4Stack=true"

### Java中因连接重置导致的 `IOException` 解决方案 在处理网络通信时,当远程服务器关闭连接并发送 TCP RST 数据包时,客户端可能会遇到 `java.io.IOException: Connection reset by peer` 的异常情况。这种问题通常发生在负载均衡器(如 HAProxy)重新分配流量或数据库连接池管理不当的情况下。 #### 原因分析 1. **HAProxy 行为** 当 HAProxy 关闭连接以实现流量再平衡时,它会通过发送 TCP RST 来终止当前连接[^2]。这可能导致客户端接收到该信号后抛出 `IOException` 异常。 2. **WebLogic 连接池行为** WebLogic 中的 JDBC 连接池可能未能及时检测到已失效的连接,在尝试使用这些连接执行查询操作时引发异常[^1]。 3. **Netty 和 NIO 实现细节** Netty 使用基于 Sun NIO 的类库来处理底层 IO 操作。如果底层套接字被强制关闭,则会触发 `Connection reset by peer` 错误。 4. **SQLRecoverableException** 如果应用程序正在访问数据库,并且由于网络中断或其他原因导致连接丢失,则可能出现 `SQLRecoverableException: I/O Exception: Connection reset`[^3]。 --- #### 解决方法 ##### 方法一:增强应用层健壮性 可以通过捕获异常并对失败的操作进行重试机制设计,从而提高系统的容错能力: ```java public void executeQueryWithRetry(String query, int maxRetries) { int retryCount = 0; boolean success = false; while (retryCount < maxRetries && !success) { try { // 执行 SQL 查询逻辑 Statement stmt = connection.createStatement(); ResultSet rs = stmt.executeQuery(query); // 处理结果集... success = true; // 成功完成则退出循环 } catch (SQLException e) { if ("I/O Exception: Connection reset".equals(e.getMessage())) { System.out.println("Detected connection reset. Retrying..."); retryCount++; // 尝试重建连接 reconnectDatabase(); } else { throw e; // 非预期错误直接抛出 } } } if (!success) { throw new RuntimeException("Failed to execute query after " + maxRetries + " attempts."); } } ``` 上述代码片段展示了如何通过增加重试次数以及调用自定义函数 `reconnectDatabase()` 动态恢复断开的数据库链接。 --- ##### 方法二:优化 HAProxy 设置 调整 HAProxy 参数可以减少不必要的连接中断现象发生频率: - 启用 PROXY 协议支持以便更精确识别源地址; - 调整超时时间参数 (`timeout client`, `timeout server`) 让长活请求有更多机会正常结束而非被迫切断; - 替代硬性的 RESET 方式改用优雅关闭模式(`option tcpka`)保持持久化会话存活状态直到自然终结为止。 配置样例如下所示: ```plaintext frontend http-in bind *:80 mode http option forwardfor timeout client 5m backend app-servers balance roundrobin mode http option tcpka # Enable keep-alive on idle connections. timeout connect 5s # Timeout for establishing a connection with backend servers. timeout server 5m # Maximum inactivity time allowed between two consecutive packets from/to the same server. default-server inter 5s rise 2 fall 3 server s1 192.168.1.1:80 check server s2 192.168.1.2:80 check ``` --- ##### 方法三:改进连接池策略 对于像 WebLogic 提供的服务端组件来说,合理设置其内部维护的空闲资源销毁周期至关重要。具体措施如下: - 缩短最大空闲时限(maxIdleTime),促使不再活跃的数据通道尽快释放掉; - 开启测试功能(testConnectionsOnReserve=true),每次获取前验证可用性防止拿到已经损坏的对象实例继续利用造成崩溃风险; 示例 XML 片段展示部分属性修改方式: ```xml <jdbc-connection-pool> ... <max-idle-time>30</max-idle-time> <!-- 秒 --> <test-connections-on-reserve>true</test-connections-on-reserve> ... </jdbc-connection-pool> ``` 以上更改有助于降低因为长时间未使用的陈旧管道突然遭到破坏而产生的影响概率。 --- #### 总结 针对由外部因素引起的 `java.io.IOException: Connection reset by peer` 类型的问题,可以从多个角度入手加以缓解甚至彻底消除隐患。包括但不限于引入自动化的补偿流程、精细化调控中介设备的工作特性还有完善基础架构层面的设计思路等方面综合考虑实施最佳实践组合拳出击达到理想效果目标。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值