I took another look around the wiki last night and noticed the error I got from my modified proggy is exactly like the other error described here:
http://jira.red5.org/browse/SN-5 Shud the 2 be merged? And Luke, thanks for the directions. I tried manually firing the disconnect events when streams are unsubscribed and unpublished and used the closeChannel command to close the audio/video/data channels but it still doesn't seem to work for me =( but I'm super confused by all the code so I must be doing something wrong ( probably I'm doing it in the wrong sequence or other additional resources needs to be released elsewhere. ) thanks NK On 1/24/07, Luke Hubbard <[EMAIL PROTECTED]> wrote: > I also have a go at fixing this bug last night but got lost in the stream > code. Basically I think the problem is ConnectionConsumer grabs some > channels, and does not release them. There is even a todo in there about > releasing them. However the event to tell the connection consumer to that > the provider has disconnected doesnt seem to make it to the connection > consumer. I will ask steven for help as he should know. > > - Luke > > > On 1/25/07, Nankun Huang <[EMAIL PROTECTED]> wrote: > > oops, I sent the previous email prematured.. damn google mail enter > > key.. anyway to continue where I left off... > > > > 1, When a stream is deleted by the > > deleteStreamById(streamId) function, it did not call the > > unreserveStreamId(int streamId) function!! Therefore, it causes the > > reservedStreams variable to show that the stream is still reserved > > EVEN THOUGH its actually gone from the streams[] Array. > > > > 2, I tried to trace who is the one that is called the > > deleteStreamById() function and came to the > > org.red5.server.stream.StreamService class. From there, > I found that > > the function which calls the delete stream is the: closeStream() > > function on line 59. So I thought maybe, by changing > > deleteStreamById(streamId) to unreserveStreamId(streamId) ( since > > unreserve stream function calls delete stream anyways ), it'll remove > > the offending problem. > > > > However when I did that, it choose to give me a DIFFERENT error > > instead!! Here's the error > > > > [ERROR] 233079 SocketAcceptorIoProcessor-0.0:( > > org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.error > ) Error in > > packet at 140 > > java.lang.NullPointerException > > at > org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodeHeader(RTMPProtocolDecoder.java:295) > > at > org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodePacket(RTMPProtocolDecoder.java:217) > > at > org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decode > (RTMPProtocolDecoder.java:114) > > at > org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodeBuffer(RTMPProtocolDecoder.java:87) > > at > org.red5.server.net.rtmp.codec.RTMPMinaProtocolDecoder.decode(RTMPMinaProtocolDecoder.java > :48) > > at > org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:157) > > at > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java > :501) > > at > org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoFilterChain.java:51) > > at > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java > :787) > > at > org.apache.mina.common.support.AbstractIoFilterChain$1.messageReceived(AbstractIoFilterChain.java:110) > > at > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java > :501) > > at > org.apache.mina.common.support.AbstractIoFilterChain.messageReceived(AbstractIoFilterChain.java:492) > > at > org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.java:284) > > at > org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcessor.java:244) > > at > org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400(SocketIoProcessor.java:41) > > at > org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:565) > > > > It seems to me that its calling the decoding function over and over > > again with some kind of a null pointer. blah. I dunno. hope this > > helps. I wish I could be more of a help but I dunno any of this spring > > mina stuff =( so this is as far as I'll go. > > > > NK > > > > On 1/24/07, Nankun Huang <[EMAIL PROTECTED] > wrote: > > > I did a bit more of an investigation into this with the wild hope that > > > I might debug this ( with my noob java skillz ). So I set up the > > > eclipse debugger and fired it away. Now I finally give up after 3 > > > hours. However I did have some interesting finds. > > > > > > Firstly, I started noticing the problem in: > > > org.red5.server.net.rtmp.RTMPConnection.java > > > As i used my program to subscribe and unsubscribe to my own streams, I > > > noticed something: > > > > > > 1, When a stream is deleted by the > > > deleteStreamById(streamId) function, it did not call the > > > unreserveStreamId(int streamId) function!! therefore, this causes the > > > > > > On 1/24/07, Nankun Huang <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > Ok, sorry I didn't look at the wiki more carefully =) This > > > > actually happens on the playback side too. When a client subscribe to > > > > more than 12 streams ( one after another ), the client will not be > > > > able to subscribe to any new ones anymore. Thnx > > > > > > > > NK > > > > > > > > > > > > On 1/24/07, Chris Allen <[EMAIL PROTECTED]> wrote: > > > > > Sorry for the confusion. I thought that it had been fixed already. > It is a > > > > > priority to have it fixed before the rc2 release though. > > > > > > > > > > -Chris > > > > > > > > > > > > > > > On 1/24/07, Thijs Triemstra < [EMAIL PROTECTED]> wrote: > > > > > > There's a bug for this issue on > > > > > http://jira.red5.org/browse/SN-14 > > > > > > > > > > > > Thijs > > > > > > > > > > > > > > > > > > Op 24-jan-2007, om 11:27 heeft Nankun Huang het volgende > geschreven: > > > > > > > > > > > > > Hi all, > > > > > > > According to an email which I got from this list yesterday, it > was > > > > > > > stated that the 12 connection limit bug is fixed. I was > overjoyed and > > > > > > > rushed to test out if this was the case. However after > downloading the > > > > > > > lattest trunk and compiling, this does not seem to be the case. > There > > > > > > > also isn't a bug report on the wiki about this and when the bug > was > > > > > > > reported unto the mailing list earlier ( by someone else, not me > ), it > > > > > > > was December and the issue didn't seem to have gotten much > attention > > > > > > > from the dev team. Here's a simple adobe flex program which I > made > > > > > > > that illustrates the bug. the MXML source file is below: > > > > > > > > > > > > > > The bug happens when a user publishes a stream, unpublish it, > publish > > > > > > > a new stream with a different stream name and then unpublish it > > > > > > > again... rinse and repeat about 12 times and it stops working ( > I no > > > > > > > longer get the publish success message ). I guess the intended > > > > > > > functionality is that each user shouldnt' publish more than 12 > > > > > > > simultaneous streams which makes sense.. however in this case, > once a > > > > > > > stream is unpublished, it should just get deleted and no longer > > > > > > > "count" toward the user. Thanks for your attention. > > > > > > > > > > > > > > It seems that when I reach the limit of the number of streams > that can > > > > > > > be published, red5 gives me this error in the console > > > > > > > > > > > > > > [java] [WARN] 575703 pool-1-thread-2: > > > > > > > ( org.red5.server.net.rtmp.RTMPHandler > > > > > > > .warn ) Unhandled ping: Ping: 3, 0, 0, -1 > > > > > > > [java] 00 03 00 00 00 00 00 00 00 00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------ and here's the mxml file > > > > > > > > > > > > > > <?xml version="1.0" encoding="utf-8"?> > > > > > > > <mx:Application xmlns:mx=" http://www.adobe.com/2006/mxml"; > > > > > > > layout="absolute"> > > > > > > > <mx:Script> > > > > > > > <![CDATA[ > > > > > > > import mx.utils.UIDUtil ; > > > > > > > import flash.net.NetStream; > > > > > > > import flash.net.NetConnection; > > > > > > > import flash.net.ObjectEncoding; > > > > > > > import flash.media.Microphone; > > > > > > > import flash.events.NetStatusEvent; > > > > > > > import mx.controls.Alert ; > > > > > > > > > > > > > > //set to AMF0 for red5 > > > > > > > NetConnection.defaultObjectEncoding > = > > > > > ObjectEncoding.AMF0; > > > > > > > > > > > > > > private var nc: NetConnection; > > > > > > > private var ns:NetStream; > > > > > > > private var ns_play:NetStream; > > > > > > > private var stream_name:String; > > > > > > > > > > > > > > //connect to server > > > > > > > private function connect():void{ > > > > > > > nc = new NetConnection(); > > > > > > > nc.client = this; > > > > > > > nc.addEventListener(NetStatusEvent.NET_STATUS, > > > > > > > netStatusHandler); > > > > > > > nc.connect ( "rtmp://localhost/fitcDemo"); > > > > > > > } > > > > > > > > > > > > > > //useless callbcks from fitcDemo > > > > > > > public function setId( id:String):void{ > > > > > > > trace("server invoked set ID: "+ id); > > > > > > > } > > > > > > > > > > > > > > public function newStream( id:String):void{ > > > > > > > trace("server invoked newStream: "+ id); > > > > > > > } > > > > > > > //start to publish the stream > > > > > > > public function startPub():void{ > > > > > > > var mic:Microphone = Microphone.getMicrophone(); > > > > > > > // generate a unique stream name every time with > the > > > > > > > unique ID generator > > > > > > > stream_name = UIDUtil.createUID(); > > > > > > > > > > > > > > this.btnPub.enabled = false; > > > > > > > ns = new NetStream(nc); > > > > > > > ns.attachAudio( mic ) > > > > > > > ns.addEventListener( NetStatusEvent.NET_STATUS, > > > > > > > netStreamStatusHandler); > > > > > > > ns.publish( stream_name ); > > > > > > > > > > > > > > } > > > > > > > > > > > > > > //stop publishing the stream > > > > > > > public function stopPub():void{ > > > > > > > ns_play.close(); > > > > > > > ns.close(); > > > > > > > this.btnPub.enabled = true; > > > > > > > this.btnStop.enabled= false; > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > private function netStatusHandler > > > > > > > (event:NetStatusEvent):void{ > > > > > > > trace(event.info.code); > > > > > > > if(event.info.code == > > > > > > > " NetConnection.Connect.Success") { > > > > > > > this.btnPub.enabled = true; > > > > > > > Alert.show('connected to server!!'); > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > > > > > > > > //when publish is successful, play the stream > > > > > > > private function netStreamStatusHandler > > > > > > > (event:NetStatusEvent):void{ > > > > > > > if( event.info.code == "NetStream.Publish.Start" > ) { > > > > > > > trace(event.info.code ); > > > > > > > ns_play = new NetStream(nc); > > > > > > > ns_play.play( stream_name ); > > > > > > > this.btnStop.enabled = true; > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > > > > > > > > ]]> > > > > > > > </mx:Script> > > > > > > > <mx:Panel x="10" y="10" width="284" height="256" > layout="absolute" > > > > > > > title="Red5 12 connection limit bug "> > > > > > > > <mx:Button x="10" y="10" label="Connect" > click="connect()"/> > > > > > > > <mx:Button x="10" y="40" label="Publish & Play" > > > > > > > mouseDown="startPub()" enabled="false" id="btnPub"/> > > > > > > > <mx:Button x="125" y="40" label="Stop" > mouseDown="stopPub()" > > > > > > > enabled="false" id="btnStop"/> > > > > > > > <mx:Text x="10" y="70" text="Press connect to connect to > > > > > > > server (pop up will inform you that its connected), when > connected > > > > > > > press publish & play to publish with your own mic and play > the > > > > > > > same stream you published. Press stop to stop the publishing and > > > > > > > playing. Do this for 12 times, it'll die on the 13th time, > > > > > > > illustrating the bug. Somtiems it fails before 12 times." > > > > > > > width="251"/> > > > > > > > </mx:Panel> > > > > > > > </mx:Application> > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Red5 mailing list > > > > > > > [email protected] > > > > > > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Red5 mailing list > > > > > > [email protected] > > > > > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Red5 mailing list > > > > > [email protected] > > > > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Red5 mailing list > > [email protected] > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > > > _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
