Mule NIO

A transport for MINA based protocols. 

Features:

• Efficient for protocols that uses long lasting connections, permanent connections, sending of large quantities of data, streaming
• Optimized threads utilization (manage thousand of connections with few threads)
• Since it uses the Mina library it will ease the integration of protocols made for Mina with Mule
• Mina is rapidly evolving and performance improvements in Mina will be reflected on this transport
  

WARNING: THIS PAGE IS A DRAFT

Quick start

Use a mina protocol in mule is really simple:

Just specify an endpoint address starting with "mina://" and a protocolFactory: 

<inbound-router>
	<endpoint name="simpleProtocolIn" address="mina://localhost:8888">
		 <properties>
			<property name="protocolFactory" value="org.mule.providers.mina.codec.codecs.SimpleTextLineCodecFactory" />
		</properties>
	</endpoint>
</inbound-router>

In the example above we'll start a server listening on localhost at the port 8888 (as specified in the address property: "mina://localhost:8888")

We have also defined a "protocolFactory". This is a class that provide a coder and a decoder for the byte stream received from the connected clients. In this example we have used one of the codecs provided with the transport.

You can use the codecs from the org.mule.providers.mina.codec.codecs package as examples if you want to implement your own.

 Example

Start a mule instance with this component to do a simple test:

<mule-descriptor name="SimpleProtocol" implementation="org.mule.components.simple.EchoComponent">
	<inbound-router>
		<endpoint address="mina://localhost:8888" synchronous="true">
			 <properties>
				<property name="protocolFactory" value="org.mule.providers.mina.codec.codecs.SimpleTextLineCodecFactory" />
			</properties>
		</endpoint>
	</inbound-router>
</mule-descriptor>

Start Mule, connect to localhost:8888 with putty (connection type: raw) or netcat, type something and press enter. You will receive the echo back.

 Asynchronous usage

By default the component code will run in the same thread of Mina, and so every I/O operation will block the entire server.
Since the majority of components will need to read from the network or the disk, it is likely that you'll need a different approach.

Luckily the solution is easy: run the component in a different thread than Mina

<mule-descriptor name="SimpleProtocol" implementation="org.mule.components.simple.EchoComponent">
	<inbound-router>
		<endpoint address="mina://localhost:8889" synchronous="false">
			 <properties>
				<property name="protocolFactory" value="org.mule.providers.mina.codec.codecs.SimpleTextLineCodecFactory" />
			</properties>
		</endpoint>
	</inbound-router>
	<outbound-router>
		<router className="org.mule.routing.outbound.OutboundPassThroughRouter">
			<endpoint address="mina://localhost:8889" />
		</router>
	</outbound-router>
</mule-descriptor>

Just specify synchronous="false" and an outbound router with the same address as the inbound one.

In this way the component will be called in an asynchronous way, and so in a different thread than the one used by Mina. 

It's mandatory to specify the outbound router because in an asynchronous processing a request is completely independent from the response.
When a client connected to our server send a message, Mule will dispatch the associated event and will not wait for a response.
It is demanded to our effort to properly configure the routes so that a response will be eventually sent to the client.

Obviously there can be as many components as you like between the server inbound endpoint and the outbound one:

<mule-descriptor name="SimpleProtocol" implementation="org.mule.components.simple.EchoComponent">
	<inbound-router>
		<endpoint address="mina://localhost:8889" synchronous="false">
			 <properties>
				<property name="protocolFactory" value="org.mule.providers.mina.codec.codecs.SimpleTextLineCodecFactory" />
			</properties>
		</endpoint>
	</inbound-router>
	<outbound-router>
		<router className="org.mule.routing.outbound.OutboundPassThroughRouter">
			<endpoint address="vm://one" />
		</router>
	</outbound-router>
</mule-descriptor>

<mule-descriptor name="One" implementation="org.mule.components.simple.BridgeComponent"
				 inboundEndpoint="vm://one" outboundEndpoint="vm://two" />

<mule-descriptor name="Two" implementation="org.mule.components.simple.BridgeComponent"
				 inboundEndpoint="vm://two" outboundEndpoint="vm://three" />

<mule-descriptor name="Three" implementation="org.mule.components.simple.BridgeComponent"
				 inboundEndpoint="vm://three" outboundEndpoint="mina://localhost:8889" />

In this example we have changed the outbound router to "vm://one". Notice the outboundEndpoint of the last component ("Three"): it is where the response is finally sent back to the client.
The message will do this route: Our Client -> The Net -> Received by Mina -> SimpleProtocol Component -> One Component -> Two Component -> Three Component -> Mina -> The net -> Our Client.

 Synchronous vs Asynchronous

In the previous example, we have made a simple echo component that listen to a port and accept carriage-return-delimited messages.

It might sound quite simple but it is also really powerful. In this example, we could connect as many clients (in the order of thousands) without problem.
This is because, unlike other transports, Mina will not spawn a different thread for each connected client.
In this way the resource consumption of a connection is really small.

However the EchoComponent we used is a really simple one-liner component.
More precisely it is cpu-bound: it doesn't do I/O operations like read from a disk or database.

Those I/O operations can be a problem because they block the component thread, and Mina too!
This mean that the server, including other connected clients, will block until this I/O operation ends.

 Configuration

 TODO

Author

 Marco D'Alia - minamule at madarco .it
 www.madarco.net