Aloha, as sebastian already mentioned the streamBroadcastClose still gets called, when this appLeave problem shows up. my workaround is to put everything i would do on leave, disconnect,.. in streamBroadcastClose.
that allows me to keep up my development. thx sebastian -Adam- yes i have seen that problem too and commented it there, but i was also unable to reproduce it. It seems to be quite hard to find a precise test scenario for that issue. i am working with macOSx compiled with java 5. But i think that makes no difference. sebastian 2007/2/24, Adam <[EMAIL PROTECTED]>: > > hi sebastian, > > iam facing the exact same problem. > > right now iam developing a kind of chat/video conference. > the appLeave event isnt called. > also sometimes iam facing following exception when a client > disconnects; > > latest trunk r1743. windows xp > > > [ERROR] 111203 SocketAcceptorIoProcessor-0.0:( > org.red5.server.net.rtmp.BaseRTMPHandler.error ) Exception > java.lang.NullPointerException at > org.red5.server.so.SharedObject.sendUpdates( > *SharedObject.java:271*) > at > org.red5.server.so.SharedObject.notifyModified(*SharedObject.java:359*) > at org.red5.server.so.SharedObject.endUpdate(*SharedObject.java:617*) > at org.red5.server.so.SharedObjectScope.endUpdate(*SharedObjectScope.java > :162*) > at org.red5.server.so.SharedObjectScope.dispatchEvent(* > SharedObjectScope.java:382*) > at org.red5.server.net.rtmp.RTMPHandler.onSharedObject(*RTMPHandler.java > :477*) > at org.red5.server.net.rtmp.BaseRTMPHandler.messageReceived(* > BaseRTMPHandler.java:167*) > at org.red5.server.net.rtmp.RTMPMinaIoHandler.messageReceived(* > RTMPMinaIoHandler.java:117*) > at > org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageR eceived > (*AbstractIoFilterChain.java:700*) > at > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageRece ived > (*AbstractIoFilterChain.java:361*) > at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(* > AbstractIoFilterChain.java:53*) > at > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.message Received > (*AbstractIoFilterChain.java:785*) > at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush( > *SimpleProtocolDecoderOutput.java:62*) > at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(* > ProtocolCodecFilter.java:187*) > at > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageRece ived > (*AbstractIoFilterChain.java:361*) > at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(* > AbstractIoFilterChain.java:53*) > at > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.message Received > (*AbstractIoFilterChain.java:785*) > at > org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageR eceived > (*AbstractIoFilterChain.java:616*) > at > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageRece ived > (*AbstractIoFilterChain.java:361*) > at > org.apache.mina.common.support.AbstractIoFilterChain.fireMessageReceived (* > AbstractIoFilterChain.java:352*) > at org.apache.mina.transport.socket.nio.SocketIoProcessor.read(* > SocketIoProcessor.java:288*) > at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(* > SocketIoProcessor.java:248*) > at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$500(* > SocketIoProcessor.java:49*) > at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(* > SocketIoProcessor.java:540*) > at org.apache.mina.util.NamePreservingRunnable.run(* > NamePreservingRunnable.java:43*) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(* > ThreadPoolExecutor.java:885*) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(* > ThreadPoolExecutor.java:907*) > at java.lang.Thread.run(*Thread.java:619*) > [DEBUG] 111203 SocketAcceptorIoProcessor-0.0:( > com.main.streamactor.Application.debug ) #[streamBroadcastClose CId:0] > stream broadcast close: test9 > [INFO] 111203 SocketAcceptorIoProcessor-0.0:( > com.main.streamactor.Application.info ) #[appLeave CId:0] Client left app > 0 > > i added a sample fla to ticket > <http://jira.red5.org/browse/APPSERVER-58> http://jira.red5.org/browse/APPSERVER-58 to reprocude this exception. > > FYI > > -Adam- > > > hi, > I've heard about ghost-conenction problems in the past but I could > workaround as there are 3 events when a user leaves a room and > appDisconnect did work stable. But at the moemnt non of these Events > is thrown sometimes. So you got ghost connections left in your scope. > > I filled a bug with the hole description to reproduce: > *http://jira.red5.org/browse/APPSERVER-68*<http://jira.red5.org/browse > /APPSERVER-68> I think its a Issue inside the Application Server? Is > there a workaround to get rid of ghost connections? I have seen in my > application that the *streamBroadcastClose* is always thrown without > problems. So I think i will add a check after that in my app which > checks for *ghost connections* by making a ping-roundtrip. Any other > ideas to workaround? thx & regards > sebastian > > _______________________________________________ > Red5 mailing list > [email protected] <http://osflash.org/mailman/listinfo/red5_osflash.org> http://osflash.org/mailman/listinfo/red5_osflash.org > >
_______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
