>> One interesting thing to test might be to try the RTMPT standalone version, just to compare to see if its a basic session handling issue or just an issue if you use the Servlet version.
It seems to be good idea! Thanks! Somehow I always able to enter the room or to the OM, but room_id in Client is always null :( On Thu, Aug 1, 2013 at 4:49 PM, [email protected] <[email protected] > wrote: > Sorry I misunderstood you. > > I am testing rtmpt by manipulating the config.xml and setting the rtmpport > to a nonsense value to force it using RTMPT. > > *Test 1: Using the flash standalone version. When I enter the conference > room using RTMPT it does not login the user correctly at all. You can see > error log messages.* > > but you can also see it in the client UI: > There user list does not show the user. There is something broken during > the login commands. > I can debug the issue further to track down which calls fail but somehow > the user never really is logged in, so I guess the room Id is never set to > his session object. > > If you look at the connection console: ( > http://localhost:5080/openmeetings/#admin/connection): > You can see that the RTMPT connected user is not even listed in the list > of active connections. > > So I suspect that the entire connection mechanism in Red5 using RTMPT is > broken, at least with the red5 revision that I am testing (Red5 Server > 1.0.2 $Rev: 4697) .That should be the latest one. > > *Test 2: Using the flash standalone version. This time the RTMPT serlvet > somehow lets me inside the room,* > anyhow looking at: > http://localhost:5080/openmeetings/#admin/connection) > I can still see 3 connections, one to scope hibernate and two in the room, > but actually it should be just two in the room and the one to type > hibernate should be closed when I disconnected to enter the conference room. > > After a while the hibernate connection somehow is "gone" (without me doing > anything). It seems like the Servlet does not really do actively monitor > things in "real time" it simply does some kind of timeout. Or is broken. > > However the room_id is correctly set, when I request the Screensharing > client it contains: > <argument>openmeetings/7</argument> > > And the RTMPT version will start up. However if I click start sharing or > start recording it will throw: > ERROR 08-01 21:22:41.456 RTMPProtocolEncoder.java 19233 111 > org.red5.server.net.rtmp.codec.RTMPProtocolEncoder [Thread-19] - Error > encoding > > java.lang.NullPointerException: null > at > org.red5.server.net.rtmp.codec.RTMPProtocolEncoder.dropMessage(RTMPProtocolEncoder.java:225) > ~[red5-server.jar:na] > at > org.red5.server.net.rtmp.codec.RTMPProtocolEncoder.encodePacket(RTMPProtocolEncoder.java:133) > ~[red5-server.jar:na] > at > org.red5.server.net.rtmp.codec.RTMPProtocolEncoder.encode(RTMPProtocolEncoder.java:109) > ~[red5-server.jar:na] > at > org.red5.client.net.rtmpt.BaseRTMPTConnection.write(BaseRTMPTConnection.java:240) > ~[red5-client-1.0.2-RC1.jar:1.0.2-RC1] > at org.red5.server.net.rtmp.Channel.write(Channel.java:138) > ~[red5-server.jar:na] > at org.red5.server.net.rtmp.Channel.write(Channel.java:107) > ~[red5-server.jar:na] > at > org.red5.server.stream.consumer.ConnectionConsumer.pushMessage(ConnectionConsumer.java:183) > ~[red5-server.jar:na] > at > org.red5.client.net.rtmp.BaseRTMPClientHandler.publishStreamData(BaseRTMPClientHandler.java:565) > ~[red5-client-1.0.2-RC1.jar:1.0.2-RC1] > at > org.apache.openmeetings.screen.webstart.CaptureScreen.pushVideo(CaptureScreen.java:130) > ~[openmeetings-screenshare-3.0.0-SNAPSHOT.jar:na] > at > org.apache.openmeetings.screen.webstart.CaptureScreen.run(CaptureScreen.java:87) > ~[openmeetings-screenshare-3.0.0-SNAPSHOT.jar:na] > > * > * > *Test 3: Using the HTML5 version and then entering the room.* > > It seems to log me in fine using RTMPT, when I look at: > http://localhost:5080/openmeetings/#admin/connection > The room_id is correctly set in the RoomClient > > But when I click on the button to request the JNLP file I get: > ERROR 08-01 21:27:22.060 ScreenController.java 1263660 224 > org.apache.openmeetings.servlet.outputhandler.ScreenController > [http-bio-0.0.0.0-5080-exec-11] - [ScreenController] > java.lang.Exception: Client has no room > > I could repeat this use case / test and reproduce the issue. However I > sometimes run again in scenario 1 again where simply the user is not even > shown in the list of users after I login. > > I debugged the Exception a bit, and found out: > > The Servlet is using the wrong Client Session Object! If you look at the > modified debug statement that I produced: > java.lang.Exception: Client has no room > org.apache.openmeetings.persistence.beans.room.Client@7825114a StreamId: > 3B5TYPGH9LIZJ PublicSID: 00f4343597d130cd68762da623e2b127 UserId: 1 RoomId: > null isScreenClient: false flvRecordingId: null screenPublishStarted: false > flvRecordingMetaDataId: null isRecording: false isAVClient: false > broadCastID: -2 avsettings: server: null > > => And then look at the > http://localhost:5080/openmeetings/#admin/connection > > StreamId: 3B5TYPGH9LIZJ is simply not the Client object that is in the > room, it is another one! > So we basically request the screensharing client with the wrong publicSID. > But where this is coming from, I don't know. > > This does simply work fine using RTMP instead of RTMPT. > Or in other words, somehow the RTMPT connection has major issues with > handling the connection. > > ---------------------- > > I am a bit reluctant to debug that further, I made now 3 tests and receive > randomly results where either the login into the room is incomplete, > sessions on the server are not correctly closed or somehow the client does > not seem to process certain calls. That just does not seem to be worth now > to debug this to the very end and is seems to be quite unstable. > > From my point of view, the RTMPT Servlet has some major issue in the > connection establishing and session handling. > Sessions get mixed up, calls might be dropped, and the session stay open > way longer then needed. > > One interesting thing to test might be to try the RTMPT standalone > version, just to compare to see if its a basic session handling issue or > just an issue if you use the Servlet version. > > > -------------------- > > Additional logging/error/warnings statements in the red5/server log. But I > guess you experienced the same. > > Thousand of this type: > [DEBUG] [http-bio-0.0.0.0-5080-exec-3] > org.red5.server.net.rtmpt.RTMPTConnection - Pending messages out: 0 > > And: > [WARN] [http-bio-0.0.0.0-5080-exec-10] > org.red5.server.net.rtmp.RTMPConnManager - Connection not found for > Q1KMWA85XXNZQ > [WARN] [http-bio-0.0.0.0-5080-exec-10] > org.red5.server.net.rtmpt.RTMPTServlet - Null connection for session id: > Q1KMWA85XXNZQ > > > > > > 2013/8/1 Maxim Solodovnik <[email protected]> > >> Hello Sebastian, >> >> RTMPT configuration was changed according to the Paul's comments: [1] >> Since then there is no need in additional port for RTMPT (OM HTTP port is >> always used, and can be redirected via Apache or changed to be 80 in >> red5.properties) >> >> RTMP client is broken in red5: [2] >> RTMPT is working if started from the debugger (with the Exceptions you >> have described, already reported to Paul) >> >> The issue I ask you to take a look at is: >> In case user enters the room using RTMPT *.jnlp file is failed to be >> created since room_id == null >> >> [1] https://groups.google.com/d/topic/red5interest/14I7Ya2WjgQ/discussion >> [2] https://groups.google.com/d/topic/red5interest/2_JuBOY8WhU/discussion >> >> >> >> On Thu, Aug 1, 2013 at 2:34 PM, [email protected] < >> [email protected]> wrote: >> >>> I can see in the source code that the RTMPT port is no more configurable. >>> Actually setting rtmpt to port 443 was a common way to solve 99% of all >>> Firewall issues. >>> How would you do that now? You have to set the http port to 443 ? >>> >>> And I don't know how stable the RTMPT Servlet is. There have been issue >>> with it in the past. >>> What was the reason for that change ? >>> >>> And screenharing over RTMPT does not work for me at all. Same as >>> RTMP.But the behaviour is slightly different. >>> RTMP version throws handshake error. >>> >>> RTMPT does not but it has other exceptions. In the console of the RTMPT >>> JavaWebStart application you can find lots of exceptions throws like this: >>> >>> ERROR 08-01 19:28:26.894 RTMPProtocolEncoder.java 34725 111 >>> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder [Thread-19] - Error >>> encoding >>> java.lang.NullPointerException: null >>> at >>> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder.dropMessage(RTMPProtocolEncoder.java:225) >>> ~[red5-server.jar:na] >>> at >>> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder.encodePacket(RTMPProtocolEncoder.java:133) >>> ~[red5-server.jar:na] >>> at >>> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder.encode(RTMPProtocolEncoder.java:109) >>> ~[red5-server.jar:na] >>> at >>> org.red5.client.net.rtmpt.BaseRTMPTConnection.write(BaseRTMPTConnection.java:240) >>> ~[red5-client-1.0.2-RC1.jar:1.0.2-RC1] >>> at org.red5.server.net.rtmp.Channel.write(Channel.java:138) >>> ~[red5-server.jar:na] >>> at org.red5.server.net.rtmp.Channel.write(Channel.java:107) >>> ~[red5-server.jar:na] >>> at >>> org.red5.server.stream.consumer.ConnectionConsumer.pushMessage(ConnectionConsumer.java:183) >>> ~[red5-server.jar:na] >>> at >>> org.red5.client.net.rtmp.BaseRTMPClientHandler.publishStreamData(BaseRTMPClientHandler.java:565) >>> ~[red5-client-1.0.2-RC1.jar:1.0.2-RC1] >>> at >>> org.apache.openmeetings.screen.webstart.CaptureScreen.pushVideo(CaptureScreen.java:130) >>> ~[openmeetings-screenshare-3.0.0-SNAPSHOT.jar:na] >>> at >>> org.apache.openmeetings.screen.webstart.CaptureScreen.run(CaptureScreen.java:87) >>> ~[openmeetings-screenshare-3.0.0-SNAPSHOT.jar:na] >>> ERROR 08-01 19:28:29.412 RTMPProtocolEncoder.java 37243 111 >>> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder [Thread-19] - Error >>> encoding >>> java.lang.NullPointerException: null >>> at >>> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder.encodeCommand(RTMPProtocolEncoder.java:763) >>> ~[red5-server.jar:na] >>> at >>> org.red5.server.net.rtmpt.codec.RTMPTProtocolEncoder.encodeCommand(RTMPTProtocolEncoder.java:49) >>> ~[red5-server.jar:na] >>> at >>> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder.encodeCommand(RTMPProtocolEncoder.java:731) >>> ~[red5-server.jar:na] >>> at >>> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder.encodeInvoke(RTMPProtocolEncoder.java:719) >>> ~[red5-server.jar:na] >>> at >>> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder.encodeMessage(RTMPProtocolEncoder.java:499) >>> ~[red5-server.jar:na] >>> at >>> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder.encodePacket(RTMPProtocolEncoder.java:134) >>> ~[red5-server.jar:na] >>> at >>> org.red5.server.net.rtmp.codec.RTMPProtocolEncoder.encode(RTMPProtocolEncoder.java:109) >>> ~[red5-server.jar:na] >>> at >>> org.red5.client.net.rtmpt.BaseRTMPTConnection.write(BaseRTMPTConnection.java:240) >>> ~[red5-client-1.0.2-RC1.jar:1.0.2-RC1] >>> at org.red5.server.net.rtmp.Channel.write(Channel.java:138) >>> ~[red5-server.jar:na] >>> at org.red5.server.net.rtmp.Channel.write(Channel.java:107) >>> ~[red5-server.jar:na] >>> at >>> org.red5.server.net.rtmp.RTMPConnection.invoke(RTMPConnection.java:953) >>> ~[red5-server.jar:na] >>> at >>> org.red5.server.net.rtmp.RTMPConnection.invoke(RTMPConnection.java:922) >>> ~[red5-server.jar:na] >>> at >>> org.red5.server.net.rtmp.RTMPConnection.invoke(RTMPConnection.java:977) >>> ~[red5-server.jar:na] >>> at >>> org.red5.client.net.rtmp.BaseRTMPClientHandler.invoke(BaseRTMPClientHandler.java:487) >>> ~[red5-client-1.0.2-RC1.jar:1.0.2-RC1] >>> at >>> org.apache.openmeetings.screen.webstart.CoreScreenShare.sendCursorStatus(CoreScreenShare.java:178) >>> ~[openmeetings-screenshare-3.0.0-SNAPSHOT.jar:na] >>> at >>> org.apache.openmeetings.screen.webstart.CaptureScreen.run(CaptureScreen.java:94) >>> ~[openmeetings-screenshare-3.0.0-SNAPSHOT.jar:na] >>> >>> >>> >>> >>> >>> 2013/8/1 Maxim Solodovnik <[email protected]> >>> >>>> Hello Sebastian, >>>> >>>> I'm currently trying to test RTMPT screensharing (the only one working >>>> right now somehow) and found weird issue: If client trying to start >>>> screensharing and is connected via RTMPT he/she has room_id == null in >>>> Client. >>>> >>>> if RTMP is used room_id is set to the proper value. >>>> The behavior above is observed in both: "SWF login then open the room" >>>> and "Wicket enter the room". >>>> >>>> Can you please take a look at this issue? >>>> Thanks in advance! >>>> >>>> >>>> -- >>>> WBR >>>> Maxim aka solomax >>>> >>> >>> >>> >>> -- >>> Sebastian Wagner >>> https://twitter.com/#!/dead_lock >>> http://www.webbase-design.de >>> http://www.wagner-sebastian.com >>> [email protected] >>> >> >> >> >> -- >> WBR >> Maxim aka solomax >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected] > -- WBR Maxim aka solomax
