Channel Framework


TCP Channel executes I/O operations using either...


Before debugging, run: MustGather: Channel Framework problems in WebSphere Application Server

Trace string (Static trace):

TCPChannel trace must be taken statically i.e. with server restart: If not taken statically, TCPChannel will not capture “reads” For a production environment we can turn on this trace while server startup, and than turn off after startup. There will be minimal tracing going. Start this trace again dynamically during problem time.

For Plugin: MustGather: WebSphere Application Server HTTP plug-in problems

Review tools: iptrace, snoop, tcpdump, wireshark, and nettl

For wireshark:

Timeout issues

Four types of timeout...

I/O return codes...

In general they all mean the same thing: the other side closed the connection. The end result of any investigation will need to be why the other side of the connection closed it. Sometimes this can be a firewall.

Trace Analysis – IOException

  1. Find the exception:

      [7/18/12 10:15:32:638 CDT] 0000011f servlet E service SRVE0068E: Uncaught exception created in one of the service methods of the servlet TestSOAP in application test. Exception created : Async IO operation failed (1), reason: RC: 107 Transport endpoint is not connected This issue requires TCPChannel=all, set from the start of the server, and an IP Trace

  2. Follow the thread down to find the close of the socket where the IOException happened...

      [7/18/12 10:15:33:145 CDT] 0000011f AioSocketIOCh 3
      SocketChannel close starting, local: remote: