[Red5devs] Bug with scope stopping and multithreading attached fixed code

[Nathan Smith]

Hi Guys,

Recently in my project I was having issues where clients could connect to a
room scope whilst roomStop() was happening to that scope. After roomStop()
had completed Red5 would still have clients connected to the old Scope
object instance and when further clients connected Red5 would get into a
very funny state where two Scope object instances for the same scope. Even
worse when clients disconnected from the old scope roomStop() would get
called again screwing up the new scope. Anyway it was defiantly not good :-)

I think others have not come across bug because their roomStop() method
generally executes quickly and clients don't reconnect in time. My
roomStop() method saves a whole bunch of stuff that can take some time.

Anyway I resolved my issue by adding synchronization code to Scope class.
The code works as follows:

While a child scope is being removed and stopped the following will block
(only for that scope name so as minimise performance impact):

Scope#hasChildScope(String name)
Scope#hasChildScope(String type, String name)
Scope#getScope(String name)

This has fixed my issues.

I've attached the code so that Red5 developers may take lessons learned (or
just the new code) and integrate it into the trunk. The changes I've made
are marked with comment bars (feel free to remove them they are just there
for reference).

Cheers,

Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5devs_osflash.org/attachments/20080801/03a78f6b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Scope.java
Type: text/x-java
Size: 34084 bytes
Desc: not available
Url : http://osflash.org/pipermail/red5devs_osflash.org/attachments/20080801/03a78f6b/attachment-0001.bin