LCDS 2.5 RTMP mx:Consumer not able to resubscribe after disconnect (ColdFusion 8)

This post does not apply to most readers but just in case someone else runs into this bug, they will find some answers in this post and avoid wasting a lot of time hunting in search engines as I did. If you don’t run ColdFusion 8 and/or LCDS 2.5.1 using RTMP messaging, it doesn’t apply to you.

ColdFusion 8.x comes bundled with LiveCycle Data Services 2.5.1 (2 versions behind the current 3.0). If you are using this combo for publish/subscribe messaging with RTMP (only available in LCDS, not in BlazeDS), you need to be aware of a bug. If in your Flex code you create a consumer (<mx:Consumer id=”c” …) and then do a c.subscribe(), all is well and the consumer will receive messages as expected. However, if your client app becomes disconnected, even for a split second, it will not be able to resubscribe. In my particular case I had c.resubscribeInterval=5000 and c.resubscribeAttempts=-1 which should enable auto-resubscribing for the consumer in case the connection is broken. In LCDS 2.6.1 and 3.0 this works perfectly. However, in 2.5.1 there is a bug and your consumer will become deaf because it is basically resubscribing to an invalid session that the server failed to clear after the disconnect. Even a c.unsubscribe()/c.disconnect()/c.subscribe() doesn’t put things back in working order. The code runs fine with no unusual events so everything appears to be re-subscribed. Even the c.subscribed boolean property will be true… but the consumer is never going to receive another message. The workaround is extremely hackish – you have to send a garbage message (that will not be received by the broken consumer). The server will try to broadcast the published message to its consumers and discover that the old session is invalid and then clean it up. After this occurs, you can do a c.subscribe() and be back in business. However, this is not as easy as it sounds because there are timing issues and you can’t attempt to disconnect/resubscribe until the garbage message is acknowledged. You end up with code full of temporary event listeners, timers, etc. which goes way beyond an acceptable hack IMO.

This bug is only with LCDS 2.5.1 RTMP-based messaging.

The best solution is to upgrade to ColdFusion 9 and install LiveCycle Data Services 2.6.1 (instructions here) if you need RTMP messaging. This will handle disconnects/resubscribes perfectly. If you are running LCDS 2.5.1 without ColdFusion, you should upgrade to 3.0.

Currently LCDS 3.0 is not supported with ColdFusion 9 but that will change in the next version of ColdFusion. LCDS 3.0 introduces additional pub/sub messaging features including reliable messaging, message throttling and other goodies. More on this topic soon.

Lastly – if you are running ColdFusion 8, it’s time to upgrade anyways! 🙂

~ by Greg on January 15, 2010.

6 Responses to “LCDS 2.5 RTMP mx:Consumer not able to resubscribe after disconnect (ColdFusion 8)”

  1. Holy crap. You are not alone my friend. I ran into this exact same problem a while ago. I should have blogged about this. Sorry for not doing that. I never came up with the hack you did. I just waited this out tell 2.6.1 came around. Can I ask what you use for a value for the subscription timeout in the destination that your consumer subscribes too? One of the biggest issues I have had in the past with LCDS is figuring out all the timeout settings.

  2. The timeout specified in the services-config is very dependent on the type of application. In my particular app, I have it set to an hour, although now that resubscribes are working correctly, I could probably do fine with the default 20 minutes.



  3. Greg, can you comment on if you have had any issues with someone connected over RTMP and had a firewall disconnect them because the connection was idle. I have ran into this issue, where my idle-timeout value on my RTMP channel was set to the default 20 minutes. No traffic was occurring in the application, so the clients firewall would disconnect the RTMP connection after about 10 minutes. I fixed this by just sending a heartbeat to the back-end about every 4 minutes keeping the RTMP connection alive. This also worked out well for me as it kept my consumers subscription from timing out as long as the heartbeat was sent back to the client. Feel free to hit me up anytime with questions as I have dealt with a lot of issues concerning LCDS.

  4. The heartbeat is a good idea. My app is constantly sending tiny messages (every few seconds) so I sort of do the same thing.

    If the firewall shuts it down, that should throw a disconnect event and your resubscribeInterval should pick it back up, right?


  5. Yeah, as long as there is traffic going over the wire every few seconds between your client and server, the connection should stay alive. And if the connection is closed by the clients firewall for whatever reason, you should receive a disconnect event and your client should react.
    In my case, the application was a chat application where the client would just sit in all day. So, sometimes there would be no chatter going on for hours, thus the clients firewall would disconnect the connection due to it being idle. I was scratching my head for awhile thinking the LCDS backend was timing out the connection, but all along it was the clients firewall as the culprit. Things get really crazy once you start doing channel fail-over to long polling or streaming. Hey this has been a great discussion with you, as I haven’t found anyone really in the ColdFusion community doing anything substantial with LCDS.

  6. I’ve encountered this exact problem with a BlazeDS 3.2 server using long polling. I was testing scenarios where the client is disconnected, both on the client end and if BlazeDS goes down. When the service goes down and back up, the connection would always reestablish, but if the client’s network connection is disrupted, it would say it is connected but didn’t receive messages just like you described. This makes sense now that I see it’s probably because the server isn’t letting go of the bad session.

    The trouble is I’m not sure how to address the matter. How would I tell BlazeDS to send a garbage message prior to the individual client reconnecting? Hmm. Will let you know if I find anything. Let me know if you have any ideas on what I’m doing wrong.

    Thanks for the post.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: