About Inbound Endpoints¶

An inbound endpoint is a message entry point that can inject messages directly from the transport layer to the mediation layer without going through the Axis2 engine. One of the advantages of using Inbound Endpoints is in its ability to create inbound messaging channels dynamically. There are three types of inbound endpoints:

Listening Inbound Endpoints¶

A listening inbound endpoint listens on a given port for requests that are coming in. When a request is available, it is injected to a given sequence. Listening inbound endpoints support two-way operations and are synchronous.

Redeployment of listening inbound endpoints fail?

A listening inbound endpoint opens the port for itself during deployment. Therefore, if you are redeploying a listening inbound endpoint artifact, the redeployment will not be successful until the port that was previously opened for the inbound endpoint is closed.

By default, the system will wait for 10 seconds for the previously opened port to close down. If you want to increase this waiting time beyond 10 seconds, add the following system property in the deployment.toml file, which is stored in the <MI_HOME>/conf/ directory and restart the server before redeploying the artifacts.

[system.parameter]
'synapse.transport.portCloseVerifyTimeout' = 20

Note that this setting may be required in Windows environments as the process of closing a port can sometimes take longer than 10 seconds.

Polling Inbound Endpoints¶

A polling inbound endpoint polls periodically for data and, when data is available, the data is injected to a given sequence. For example, the JMS inbound endpoint checks the JMS queue periodically for messages and, when a message is available, that message is injected to a specified sequence. Polling inbound endpoints support one way operations and are asynchronous.

Event-based Inbound Endpoints¶

An event-based inbound endpoint polls only once to establish a connection with the remote server and then consumes events.