But this works only with streams.
Mention the app, where are no streams, but only text communication and
sharedobjects.

Tom


2007/2/25, Adam <[EMAIL PROTECTED]>:

 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.messageReceived
> (*AbstractIoFilterChain.java:700*)
> at
>
org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived
> (*AbstractIoFilterChain.java:361*)
> at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(*
> AbstractIoFilterChain.java:53*)
> at
>
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived
> (*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.callNextMessageReceived
> (*AbstractIoFilterChain.java:361*)
> at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(*
> AbstractIoFilterChain.java:53*)
> at
>
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived
> (*AbstractIoFilterChain.java:785*)
> at
>
org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageReceived
> (*AbstractIoFilterChain.java:616*)
> at
>
org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived
> (*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


_______________________________________________
Red5 mailing list
[email protected]
http://osflash.org/mailman/listinfo/red5_osflash.org

Reply via email to