RTMP troubles under windows XP (CF8)
There is a problem with the RTMP connection under windows XP. I didn't found the pattern yet but sometimes after restarting the ColdFusion server, it cannot use the rtmp port anymore because the server is throwing the following error in the log file:
31/08 17:08:42 user FlexMxmlServlet: init
Exception in thread "RTMP-Server" flex.messaging.endpoints.rtmp.RTMPException: The RTMP server has encountered a fatal exception starting up: Address already in use: bind
at flex.messaging.endpoints.rtmp.BaseNIORTMPServer.run(BaseNIORTMPServer.java:317)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.net.BindException: Address already in use: bind
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)
at flex.messaging.endpoints.rtmp.BaseNIORTMPServer.run(BaseNIORTMPServer.java:155)
Exception in thread "RTMP-Server" flex.messaging.endpoints.rtmp.RTMPException: The RTMP server has encountered a fatal exception starting up: Address already in use: bind
at flex.messaging.endpoints.rtmp.BaseNIORTMPServer.run(BaseNIORTMPServer.java:317)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.net.BindException: Address already in use: bind
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)
at flex.messaging.endpoints.rtmp.BaseNIORTMPServer.run(BaseNIORTMPServer.java:155)
doing a netstat -a -b I can see that port 2048 is assigned to [System] but I can't kill the process. My only solution to fix this is to reboot the machine. This is also problematic because it should switch and fall back to cf-polling-amf and it's not.
I don't see this behavior under windows 2003 Server.
I hope CF&LCDS team will find and fix this.
Are you saying that the cf-amf-polling channel doesn't work for you, or rather that when both channels are available and you provide a list of channels in the destination that when RTMP fails to connect that cf-amf-polling isn't attempted?
When 2048 is "mysteriously" busy and assigned to System, this would mean that there is a process running as the System account. Could it be that the services-config file has the Java RTMP channel uncommented *and* the CF RTMP channel uncommented? If both are uncommented (and both on 2048), when starting CF your destination will attempt to bind RTMP, but if the Java RTMP has already started first then would see this problem.
Otherwise, I have not witnessed any odd RTMP problems like this, and I test on Windows XP regularly.
Thanks!
I just have cf-rtmp and cf-amf-polling uncomment as channelsets for Messaging and Data Management. The RTMP assigment to System happens after having the server running correctly and for some reason I have to restart the server (ie add a destination).
Usually it works fine but sometimes after the restart, the instance cannot bind the rtmp channel port because it says it's already in use. I do a netstat and I have that [system] listening on that port when it was assigned to jrun before the restart.
The cf-rtmp is the only one using port 2048, no java destination was uncomment.
Regarding the cf-polling-amf, it's true, when the rtmp fails to bind, the application doesn't try to connect to cf-polling-amf.
I added a {ds.connect} to check why I wasn't getting any data and it was throwing false. Once I reproduce this again, I will run it in debug mode and with trace level on so I can check what is failing.
I'm not the only one seeing this.
there is no conflict but a problem releasing the port when restarting the server instance. When I restart my computer, LCDS integrated server starts with port 2048. I work all day and once in a while I have to restart my server instance. Sometimes everything works fine but once in a while it will complain that it couldn't bind back that port. If I perform a netstat -ab I see that [System] is locking it when it was assigned to [Jrun.exe] before the restart.
Only noticed this in windows XP, our dev box (2003 server) doesn't suffer from this no matter how many times we restart it.
I always use different ports to rtmp based channels. So it can't be a sharing port conflict.
http://www.andrzejfilipowicz.com
this is related by the fact that there are still connected clients when the server restarts and the connection persists. It has been logged but don't think they will fix it anytime soon.