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

By: lucky

lucky — Wed, 27 Apr 2011 19:28:28 +0000

Hi Dan
How can i contact you Regarding an issue in LCDS 2.6.1.. can you give me your e-mail add.

Thanks in Advance
Lucky

By: Joshua Curtiss

Joshua Curtiss — Wed, 24 Feb 2010 01:46:37 +0000

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.

By: Dan

Dan — Mon, 18 Jan 2010 16:27:30 +0000

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.

By: gregorywilson

gregorywilson — Mon, 18 Jan 2010 16:09:25 +0000

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?

Greg

By: Dan

Dan — Mon, 18 Jan 2010 16:03:39 +0000

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.

By: gregorywilson

gregorywilson — Mon, 18 Jan 2010 15:51:42 +0000

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.

Thanks!

Greg

By: Dan

Dan — Mon, 18 Jan 2010 15:41:56 +0000

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.