ASYNC IO 异常

 

最近公司接了一个客户项目,使用的环境是websphere6.1.0.0+db2 v9.项目中数据库连接池使用的是c3p0 v0.9.1.2。

可是现在系统老是死机,平均一天1次到2次。一直找不到具体原因所在,查看错误日志如下:

------Start of DE processing------ = [09-3-22 10:20:42:187 CST] , key = java.io.IOException com.ibm.ws.webcontainer.srt.SRTServletRequest.parseParameters 765
Exception = java.io.IOException
Source = com.ibm.ws.webcontainer.srt.SRTServletRequest.parseParameters
probeid = 765
Stack Dump = java.io.IOException: Async IO operation failed, reason: RC: 10054 远程主机强迫关闭了一个现有的连接。

at com.ibm.io.async.AbstractAsyncChannel.multiIO(AbstractAsyncChannel.java:443)
at com.ibm.io.async.AsyncSocketChannelHelper.read(AsyncSocketChannelHelper.java:194)
at com.ibm.ws.tcp.channel.impl.AioSocketIOChannel.readAIOSync(AioSocketIOChannel.java:205)
at com.ibm.ws.tcp.channel.impl.AioTCPReadRequestContextImpl.processSyncReadRequest(AioTCPReadRequestContextImpl.java:150)
at com.ibm.ws.tcp.channel.impl.TCPReadRequestContextImpl.read(TCPReadRequestContextImpl.java:109)
at com.ibm.ws.http.channel.impl.HttpServiceContextImpl.fillABuffer(HttpServiceContextImpl.java:4126)
at com.ibm.ws.http.channel.impl.HttpServiceContextImpl.readSingleBlock(HttpServiceContextImpl.java:3366)
at com.ibm.ws.http.channel.impl.HttpServiceContextImpl.readBodyBuffer(HttpServiceContextImpl.java:3485)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundServiceContextImpl.getRequestBodyBuffer(HttpInboundServiceContextImpl.java:1680)
at com.ibm.ws.webcontainer.channel.WCCByteBufferInputStream.bufferIsGood(WCCByteBufferInputStream.java:105)
at com.ibm.ws.webcontainer.channel.WCCByteBufferInputStream.read(WCCByteBufferInputStream.java:78)
at com.ibm.ws.webcontainer.srt.http.HttpInputStream.read(HttpInputStream.java:286)
at com.ibm.ws.webcontainer.servlet.RequestUtils.parsePostData(RequestUtils.java:297)
at com.ibm.ws.webcontainer.srt.SRTServletRequest.parseParameters(SRTServletRequest.java:1336)
at com.ibm.ws.webcontainer.srt.SRTServletRequest.getParameter(SRTServletRequest.java:994)
at com.elearningch.lms.web.filter.AuthenticationFilter.doFilter(AuthenticationFilter.java:95)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:119)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:55)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:87)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:696)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:641)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:475)
at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:463)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:92)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:744)
at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1425)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:92)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:274)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:152)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:213)
at com.ibm.io.async.AbstractAsyncFuture.fireCompletionActions(AbstractAsyncFuture.java:195)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:193)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:725)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:847)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1498)

 

因为几处连接数据库时间过长,导致等待连接的客户端出错,服务器宕机。

 

 

在 Python 3.2 中处理 IO 唤醒异常问题时,通常会涉及多线程或多进程编程以及异步编程模型。以下是关于如何解决该问题的详细说明: ### 背景分析 Python 的 `select` 或者类似的模块用于监听文件描述符的状态变化,在某些情况下可能会遇到唤醒异常(Wakeup Exception)。这种异常通常是由于信号中断或其他外部因素引起的。为了更好地理解这个问题并找到解决方案,可以从以下几个方面入手。 #### 多线程中的守护线程 守护线程是一种特殊的线程,当程序中所有的非守护线程结束运行后,守护线程也会自动终止[^1]。这有助于减少资源占用,并确保程序能够正常退出。 #### 异步编程与协程支持 自 Python 3.2 开始引入了对协程的支持,通过定义特定的方法如 `__await__`, `__aiter__`, `__anext__`, `__aenter__`, 和 `__aexit__` 来实现更高效的并发控制[^4]。这些方法允许开发者编写更加简洁和易于维护的异步代码。 --- ### 解决方案 针对 Python 3.2 中与 IO 相关的唤醒异常问题,可以采取以下措施之一来解决问题: #### 方法一:捕获并忽略唤醒异常 如果应用程序能容忍短暂的时间延迟,则可以通过简单地捕获异常并将操作重试一次的方式来规避此问题。下面是一个简单的例子展示如何做到这一点: ```python import select def safe_select(rlist, wlist, xlist, timeout=None): while True: try: readable, writable, exceptional = select.select(rlist, wlist, xlist, timeout) return readable, writable, exceptional except InterruptedError: # 捕捉由信号引发的错误 continue # 如果发生中断则重新尝试调用 select() ``` 这种方法适用于那些不需要严格实时响应的应用场景。 #### 方法二:使用更高层次库替代底层接口 对于大多数实际应用而言,直接操作低级 API 并不是最佳实践。推荐改用像 asyncio 这样的高级框架来进行网络通信和其他形式的 I/O 操作。asyncio 提供了一个完整的事件循环机制,它已经妥善处理了许多潜在的问题,包括但不限于我们讨论过的唤醒异常情况。 例如,利用 async/await 结构可以使我们的代码看起来同步执行但实际上却是异步完成的任务调度过程变得非常直观易懂。 ```python import asyncio async def fetch_data(): reader, writer = await asyncio.open_connection('localhost', 8080) message = 'GET / HTTP/1.0\r\nHost: localhost\r\n\r\n' writer.write(message.encode()) await writer.drain() data = await reader.read(100) print(data.decode()) loop = asyncio.get_event_loop() try: loop.run_until_complete(fetch_data()) finally: loop.close() ``` 上述示例展示了如何借助于 asyncio 库轻松构建客户端连接服务器读取数据的过程。 --- ### 总结 无论是采用传统的基于回调函数或者现代风格下的 coroutine-based 设计模式都可以有效缓解甚至完全消除因系统调用被意外打断所造成的麻烦。具体选择哪种途径取决于项目需求和个人偏好等因素综合考量之后再做决定。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值