Channelfw provides a framework for connecting various types of channels together to create protocol chains, both inbound and outbound. Each channel type handles specific logic within that chain and allows easy re-use of channels. For example, the bundle contains a TCP channel, which handles all socket level IO logic for connections. Channels such as SSL or HTTP can be connected on top of TCP channel to add further protocol logic, and an application channel caps the chain and provides the actual runtime logic for handling the connection.
endpoint.HTTPDefault=[host=*, port=9080] channel.DEFAULT_TCP=[type=TCPInboundChannel, endpoint=HTTPDefault] channel.DEFAULT_HTTP=[type=HTTPInboundChannel] channel.DEFAULT_DISPATCHER=[type=HTTPDispatcherChannel] chain.HTTPInboundDefault=[channels=DEFAULT_TCP\, DEFAULT_HTTP\, DEFAULT_DISPATCHER]That configuration uses three different channel types and connects them to make an inbound listening chain on *:9080. The format is <keytype>.<name>= [<props>], where the keytypes are endpoint, channel, chain, group (of chains), and factory.
wsbb.class=com.ibm.ws.bytebuffer.internal.WsByteBufferPoolManagerImpl wsbb.poolSizes=32, 1024, 8192, 16384, 24576, 32768, 49152, 65536 wsbb.poolDepths=30, 30, 30, 20, 20, 20, 10, 10That specifies the internal class used by the pooling code. This can be changed if another pool manager is wanted; however, it must be public from the providing bundle. The pool sizes and depths define the various bytebuffer pools created and how much they contain per thread.
chfw.ChainStartRetryInterval=5000 chfw.ChainStartRetryAttempts=60