Andrew Powell

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.

I've been having some issues with my hosting provider.  I thought about naming names, but I'll pass on that, for now.  I finally got fed up with the issues that I was having, so I decided to look for alternates:

I came across the folks at Slicehost.  After some asking around and doing research on my own, I figured that I'd give them a shot.  It sure is a heck of a deal.  At less than 1/2 the cost of the VPS I had at the other provider, I got the same power and flexibility that I had with the other provider.  The only difference is that I had to do all the DB and ColdFusion setup myself. 

No big deal, I can handle that.  I had to get back into linux a bit, but that was like riding a bike.  I didn't even cheat and use webmin!  

So, now I'm hosted at Slicehost and we'll see how this goes....

Even a moderately busy server logs a lot of information. The quantity of information stored in the log files is very large, not to mention also somewhat verbose. ColdFusion tries to alleviate this by splitting its info into many different logfiles. Over time, these log files can grow quite large and become very difficult to manage. Linux offers us a soltuion to this: logrotate. Logrotate runs as a daily cron job and behaves as it is told to, on any log file it is told to act upon. You can alter /etc/logrotate.conf to specify which log file to rotate and what to do when rotating that log. Log rotate allows you to act either on a schedule or when a logfile reaches a certain size. You can also compress rotated logs for space concerns. All options are configurable within logrotate.conf. Rotating your logs will keep your log files at a reasonable and manageable size, will take up less space, and, most importantly, will be easier to read. This will allow you to diagnose any issues you may have much quicker than if you hadn't rotate your logs. Interested in more detail on how to rotate your log files? Read this article.

I didn't realize how many people were actually using my RTF2HTML webservice. I understand that since the migration to the new server, it is not working. If you would let me know what your problem is and what error you are getting, please post it to the comments and I will do my best to work with you on it. If you are looking to access the service, the WSDL is: http://www.infoaccelerator.net/cfc/rtf2html.cfc?wsdl

Ok, so the problem has been diagnosed. I need to completely re-write the service to use a java object instead of a com object. This should be done relatively quickly. I just need my license for the engine to arrive and we're set to go. The WSDL will remain the same and the service will be invoked the same. I just need to update the underlying engine. This is just one of the casualties of upgrading to Linux from Windows servers!

Well, it is finally all setup. I bought a new server two weeks ago and finally got around to configuring it this weekend. My goal was this: Install ColdFusion (on JRun) and setup multiple instances. I went with RHEL 4.0 as the OS b/c I am into avoiding the evil empire at all costs. Having never setup CF in a clustered enviroment before, I was walking on unfamiliar ground. I installed the proper JVM, JRun and ColdFusion. I configured httpd.conf like it was supposed to be configured and gave it a whirl. Nothing. Turns out that you have to be very careful with your virtual hosts setup. instead of: <VirtualHost 127.0.0.1> i used: <VirtualHost *:80> ...and it worked. I had originaly used the first entry to no avail. Now that it's all configured, I am coming to you in a M$ free enviroment! Linux server, Apple desktop. Pages, Keynote, & Mail instead of Office. Free at last, free at last....you get the point.