This documentation is for WSO2 Carbon 4.4.0. View documentation for the latest release.
HTTP-NIO Transport - Carbon 4.4.0 - WSO2 Documentation
Due to a known issue do not use JDK1.8.0_151 with WSO2 products. Use JDK 1.8.0_144 until JDK 1.8.0_162-ea is released.
||
Skip to end of metadata
Go to start of metadata

HTTP-NIO transport is a module of the Apache Synapse project. Apache Synapse (as well as the WSO2 ESB) ships the HTTP-NIO transport as the default HTTP transport implementation; however, other products can install the feature that has this transport if needed. The two classes that implement the receiver and sender APIs are org.apache.synapse.transport.nhttp.HttpCoreNIOListener and org.apache.synapse.transport.nhttp.HttpCoreNIOSender respectively. These classes are available in the JAR file named synapse-nhttp-transport.jar. This non-blocking transport implementation is one of the secrets behind the superior performance figures of the WSO2 ESB. The transport implementation is based on Apache HTTP Core - NIO and uses a configurable pool of non-blocking worker threads to grab incoming HTTP messages off the wire.

HTTP relay transport

Message Relay in older versions of Carbon was simply a message builder-formatter pair. You engage it on a per-content basis. Once engaged for a given content type, messages with that content type are streamed through Carbon. It ran on same old NHTTP transport.

The Relay transport in newer versions of Carbon, is an entire HTTP transport implementation based on HTTP Core NIO. This can be used as an alternative to the NHTTP transport. It doesn't really care about the content type and simply streams all received messages through. It's as if the old Message Relay was engaged on all possible content types. The new transport also has a simpler and cleaner model for forwarding messages back and forth.

To enable this, remove the comment of the relevant HTTP transport entries in the axis2.xml. Also, comment out the usual settings for NHTTP transport receiver and sender.

Transport receiver parameters

In transport parameter tables, literals displayed in italic mode under the "Possible Values" column should be considered as fixed literal constant values. Those values can be directly put in transport configurations.

Parameter Name

Description

Required

Possible Values

Default Value

port

The port on which this transport receiver should listen for incoming messages.

No

A positive integer less than 65535

8280

non-blocking

Setting this parameter to true is vital for reliable messaging and a number of other scenarios to work properly.

Yes

true

 

bind-address

The address of the interface to which the transport listener should bind.

No

A host name or an IP address

127.0.0.1

hostname

The host name of the server to be displayed in service EPRs, WSDLs etc. This parameter takes effect only when the WSDLEPRPrefix parameter is not set.

No

A host name or an IP address

localhost

WSDLEPRPrefix

A URL prefix which will be added to all service EPRs and EPRs in WSDLs etc.

No

A URL of the form <protocol>://<hostname>:<port>/

 

Transport sender parameters

Parameter Name

Description

Required

Possible Values

Default Value

http.proxyHost

If the outgoing messages should be sent through an HTTP proxy server, use this parameter to specify the target proxy.

No

A host name or an IP address

 

http.proxyPort

The port through which the target proxy accepts HTTP traffic.

No

A positive integer less than 65535

 

http.nonProxyHosts

The list of hosts to which the HTTP traffic should be sent directly without going through the proxy.

No

A list of host names or IP addresses separated by '|'

 

non-blocking

Setting this parameter to true is vital for reliable messaging and a number of other scenarios to work properly.

Yes

true

 

  • No labels