roomStop not called when connected with RTMPT (trunk r4296)

[Richard Alam]

Hi,

I am running into an issue with shared object when using RTMPT. And I
believe the root cause is that
when using RTMPT, the roomStop method of the
MultiThreadedApplicationAdapter doesn't get called
when the last connection disconnects from a scope.

I have created a minimal application to narrow down the problem.
https://github.com/ritzalam/so-server-prob
https://github.com/ritzalam/so-client-prob

Here is the output when reproducing the problem. I've put in some
comments inside /** **/
http://pastebin.com/ejSa8MuF

Any idea why the room stop doesn't get called when using RTMPT but
gets called when using RTMP?

This problem also exist in a revision we have from about mid-March.

I'll continue poking around Red5 to see if I can fix it. Or find a workaround.

Thanks in advance.

Richard

--
---
BigBlueButton
http://www.bigbluebutton.org
http://code.google.com/p/bigbluebutton

[Richard Alam]

On Thu, Nov 10, 2011 at 5:54 PM, Richard Alam <ritz...@gmail.com> wrote:
> Hi,
>
> I am running into an issue with shared object when using RTMPT. And I
> believe the root cause is that
> when using RTMPT, the roomStop method of the
> MultiThreadedApplicationAdapter doesn't get called
> when the last connection disconnects from a scope.
>
> I have created a minimal application to narrow down the problem.
> https://github.com/ritzalam/so-server-prob
> https://github.com/ritzalam/so-client-prob
>
> Here is the output when reproducing the problem. I've put in some
> comments inside /** **/
> http://pastebin.com/ejSa8MuF
>
> Any idea why the room stop doesn't get called when using RTMPT but
> gets called when using RTMP?
>
> This problem also exist in a revision we have from about mid-March.
>
> I'll continue poking around Red5 to see if I can fix it. Or find a workaround.
>
> Thanks in advance.
>
> Richard
>

Ok...an update. I had actually nginx proxying port 80 to red5's port 5080.

I stopped nginx and changed red5.properties http.port to 80 and room
stop gets called.

We did not have this issue with Red5 0.9. Did something change in
RTMPT for red5 1.0?

Still continuing investigating...

Thanks.

[Mondain]

Nothing specific that I can recall between the two for RTMPT, but it has been awhile and I'm sure at least a few things changed.

[Richard Alam]

On Thu, Nov 10, 2011 at 6:23 PM, Mondain <mon...@gmail.com> wrote:
> Nothing specific that I can recall between the two for RTMPT, but it has
> been awhile and I'm sure at least a few things changed.

Still continuing to investigate.

I noticed that roomStop works when I set http.port to 80 but not when
I set it to 5080.

Any idea on how red5 handles port 80 and 5080?

Here's the log output for both.
http://pastebin.com/skN0F3Mv

I'd also like to mention that the only change I made is on red5.properties.

As mentioned here,
http://code.google.com/p/red5/issues/detail?id=38&can=1&q=rtmpt do I
have to enabled the RTMPT
servlet in j2ee-container.xml?

Thanks.

Richard

[Mondain]

It should handle them the same way, I can look for a hard coded port but I doubt I'll find one.

--
http://gregoire.org/
http://code.google.com/p/red5/

[Richard Alam]

On Fri, Nov 11, 2011 at 10:28 AM, Mondain <mon...@gmail.com> wrote:
> It should handle them the same way, I can look for a hard coded port but I
> doubt I'll find one.

I've narrowed it down to
http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/BasicScope.java#147

The removeEventListener method doesn't remove the connection because
the hashcode for the connection has changed from
when it was added.

When using http.port = 80, the hashcode remains the same but when
http.port = 5080, the hashcode starts at negative value but
when disconnecting, the hascode is the same as that for http.port = 80.

Here's the log output for the 2 scenarios.
http://pastebin.com/2xqnCh8M

Any idea why with http.port=5080, the connection may not be
initialized completely when adding into the scope?

I'll continue to poke around.

Thanks.

Richard

[Richard Alam]

On Fri, Nov 11, 2011 at 4:17 PM, Richard Alam <ritz...@gmail.com> wrote:
> On Fri, Nov 11, 2011 at 10:28 AM, Mondain <mon...@gmail.com> wrote:
>> It should handle them the same way, I can look for a hard coded port but I
>> doubt I'll find one.
>
> I've narrowed it down to
> http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/BasicScope.java#147
>
> The removeEventListener method doesn't remove the connection because
> the hashcode for the connection has changed from
> when it was added.
>
> When using http.port = 80, the hashcode remains the same but when
> http.port = 5080, the hashcode starts at negative value but
> when disconnecting, the hascode is the same as that for http.port = 80.
>
> Here's the log output for the 2 scenarios.
> http://pastebin.com/2xqnCh8M
>
> Any idea why with http.port=5080, the connection may not be
> initialized completely when adding into the scope?
>
> I'll continue to poke around.
>
> Thanks.
>
> Richard
>

The problem are in these two lines:
http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/net/rtmp/RTMPHandler.java#210
http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/net/rtmpt/RTMPTConnection.java#110

The second one will overwrite the first one.

When you use port 80 for rtmpt, you most like have the following uri
for your netConnection.
connection.connect("rtmpt://192.168.0.235/echo/room1/room3");

This line http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/net/rtmp/RTMPHandler.java#210
will give you a host equal to 192.168.0.235

In http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/net/rtmpt/RTMPTServlet.java#384
will get the same value for host
(http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/net/rtmpt/RTMPTConnection.java#110)

However, in the case where you explicitly set the port in your uri, i.e.
connection.connect("rtmpt://192.168.0.235:5080/echo/room1/room3");

http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/net/rtmp/RTMPHandler.java#210
will assign host = 192.168.0.235:5080

But then, http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/net/rtmpt/RTMPTServlet.java#384
will set host to 192.168.0.235

I tried changing
http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/net/rtmpt/RTMPTConnection.java#110
to
host = request.getLocalName() + ":" request.getLocalPort();

to force the host = 192.168.0.235:5080 which will work when you
explicitly add the port in your netConnection uri
connection.connect("rtmpt://192.168.0.235:5080/echo/room1/room3");

but will fail if you don't
connection.connect("rtmpt://192.168.0.235/echo/room1/room3");

Anyone can point me to where "tcUrl" in
http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/net/rtmp/RTMPHandler.java#210
is set?

The fix is to strip the port from all "tcUrl" all the time. Otherwise,
you can do
host = request.getLocalName() + ":" request.getLocalPort(); in
http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/net/rtmpt/RTMPTConnection.java#110

and force netconnection uri to explicitly have the port even for port 80
connection.connect("rtmpt://192.168.0.235:80/echo/room1/room3");

Any other ideas on how to fix this?

Pastebins for each scenario are

http://pastebin.com/d4HtLRpG
http://pastebin.com/KTCRdf4g
http://pastebin.com/D11rEQyd

[Tiago Jacobs - iMDT]

Richard, i will take care of this bug. It will need a lot of testing. You can expect this to be fixed in two weeks.

Please open a new issue at: http://code.google.com/p/red5/issues/list

Regards,
Tiago

[Richard Alam]

On Tue, Nov 15, 2011 at 10:49 AM, Tiago Jacobs - iMDT <ti...@imdt.com.br> wrote:
> Richard, i will take care of this bug. It will need a lot of testing. You
> can expect this to be fixed in two weeks.
>
> Please open a new issue at: http://code.google.com/p/red5/issues/list

Thanks Tiago.

I'm testing a fix right now. I'll create an issue with patch. You can
then take a look and see
if it's the best way to fix it.

Richard

[Tiago Jacobs - iMDT]

Ok, thanks Richard!

Tiago

[Richard Alam]

Hi Tiago,

On Tue, Nov 15, 2011 at 11:01 AM, Tiago Jacobs - iMDT <ti...@imdt.com.br> wrote:
> Ok, thanks Richard!
>
> Tiago
>
> Em 15/11/2011 13:53, Richard Alam escreveu:
>>
>> On Tue, Nov 15, 2011 at 10:49 AM, Tiago Jacobs - iMDT<ti...@imdt.com.br>
>>  wrote:
>>>
>>> Richard, i will take care of this bug. It will need a lot of testing. You
>>> can expect this to be fixed in two weeks.
>>>
>>> Please open a new issue at: http://code.google.com/p/red5/issues/list

I've opened an issue for this with an attached patch.

http://code.google.com/p/red5/issues/detail?id=160

Thanks.

Richard

[Tiago Jacobs - iMDT]

Fixed on r4298. Thanks for sending patch.

Tiago

Em 18/11/2011 18:51, Richard Alam escreveu:
> Hi Tiago,