Andrew Powell's Flex, Java, ColdFusion, and AJAX Blog

Dec 18Setting Up RTMPT Failover On LCDS

Before You Begin:

Before we dive right into the configuration, there are a few caveats that you must know about setting up RTMP Tunneling (RTMPT). First, since it binds to port 80 as a proxy to port 8080, you need to make sure those two ports are available on the IP address to which you are binding. Most J2EE servers run their default web instance on 8080, so you may have to go into your server.xml file to change that. Changing it to 8081 should work fine if you're not using that port for something else. Also, and this is very important, if you are on a UNIX type system, you must run LCDS as root. Only the root account can bind to port 80, so you must be running as root to use RTMPT on a UNIX system.

Setting Up A RTMPT Destination

In your services-config.xml file, you will need to define a new destination for your RTMPT endpoint. I like to use the current RTMP endpoint as a starting point because it's basically setup the way we need it to be, from the onset. Modify your services-config.xml file to include this:

<channel-definition id="my-rtmp" class="mx.messaging.channels.RTMPChannel">
<endpoint url="rtmp://{server.name}:2038" class="flex.messaging.endpoints.RTMPEndpoint"/>
<properties>
<idle-timeout-minutes>20</idle-timeout-minutes>
<!-- for deployment on WebSphere, must be mapped to a WorkManager available in the web application's jndi context.
<websphere-workmanager-jndi-name>java:comp/env/wm/MessagingWorkManager</websphere-workmanager-jndi-name>
-->
</properties>
</channel-definition>

      <channel-definition id="my-rtmpt" class="mx.messaging.channels.RTMPChannel">
<endpoint url="rtmpt://{server.name}:80" class="flex.messaging.endpoints.RTMPEndpoint"/>
<properties>
<idle-timeout-minutes>20</idle-timeout-minutes>
<!-- for deployment on WebSphere, must be mapped to a WorkManager available in the web application's jndi context.
<websphere-workmanager-jndi-name>java:comp/env/wm/MessagingWorkManager</websphere-workmanager-jndi-name>
-->
</properties>
</channel-definition>

You can see, we're using the same channel, we've just changed the URI to be rtmpt://{server.name}:80 instead of rtmp://{server.name}:2038 and give the new channel an id of my-rtmpt. Now that we have our channel defined, let's take a look at how we would use it.

Enabling Failover To RTMPT

Here, we're going to look at a sample destination in messaging-config.xml. This is a simple destination that uses three channels. The first connection attempt will be via RTMP. If that cannot be connected, then an attempt will be made to failover to RTMPT. I like to have a third option in there as well, just as a last resort in case all hell breaks loose with RTMP, for whatever reason. I typically use AMF Polling for this final option. It comes pre-defined for you in the services-config.xml file. This is the setup you need for a messaging destination with failover to RTMPT. Same goes for Data Mangement setup, as seen below. Typically, you do not want to use RTMP or RTMPT for remoting calls because these channels are really a bit overkill for such simple calls.

Sample Messging Destination, configured in messaging-config.xml
<destination id="failoverMessagingSampleDestination">
         <channels>
            <channel ref="my-rtmp"/>
            <channel ref="my-rtmpt"/>
            <channel ref="my-polling-amf"/>
         </channels>
   </destination>

Sample Data Management Destination, configured in data-management-config.xml
<destination id="fdms-tutorial-product">
      <adapter ref="java-dao" />
      <properties>
         <source>flex.tutorial.fdms.ProductAssembler</source>
         <scope>application</scope>
         <metadata>
            <identity property="productId"/>
         </metadata>
      </properties>
      <channels>
         <channel ref="my-rtmp"/>
         <channel ref="my-rtmpt"/>
         <channel ref="my-polling-amf"/>
      </channels>
   </destination>

RTMPT failover can be very useful for you when your users have port 2038 blocked, but the setup is not automatic. It takes some minor configuration and some care to setup the failover channel, but can really become quite handy when you need it. Keep in mind, since we're talking about RTMP and RTMPT, this only applies to LCDS. The protocol is not available in BlazeDS, but the basic failover methodology is, albeit with other channels.