A participant left the room but others see him as if he was inside

[GoogleCodeExporter]

When a user quits a room, some of the conference participants still see 
that user as a participant. If he has a camera, his image becomes black. 
When he returns to the room, others see two instances of this person.

The more people in a room, the more chance to reproduce this problem. For a 
room with 5 participants, when one of them leaves, most probably two of 
four of the rest people would still see him as if he was inside the room

Which version of OpenMeetings are you running?
0.8

Original issue reported on code.google.com by e.rovin...@gmail.com on 5 May 2009 at 10:54

[GoogleCodeExporter]

Dear E.Rovinsky! Could you please clarify the steps required to reproduce the 
problem, since it seems rather disturbing to me - for example, what do you mean 
by 
"quits the room", does he leave just buy pressing an "Exit"->"Back to Rooms", 
or by 
closing the browser? Afaik, those two are treated a bit differently. In any 
case, a 
few steps reproducing the problem in 100% cases would be great.

Original comment by volkov.r...@gmail.com on 5 May 2009 at 11:13

[GoogleCodeExporter]

1) (Optional) Register 5 different users (User1, User2, User3, User4, User5).
2) Open 5 windows of a browser you use.
3) Login using 5 different accounts.
4) Enter to some room by all the users. Using camera doesn't matter, you can 
skip 
using it.
5) Check whether all users see each other.
6) Exit by User1.
7) Check whether User2-User5 see User1 inside the room. Some of them still 
ought to 
see him.

P.S. You can use one account to enter the same room. It would be faster to 
reproduce  
but not so obvious to observe that this is the error.

Original comment by e.rovin...@gmail.com on 5 May 2009 at 11:26

[GoogleCodeExporter]

"6) Exit by User1" means "Press Exit->Back to Rooms"

Original comment by e.rovin...@gmail.com on 5 May 2009 at 11:29

[GoogleCodeExporter]

Thanks, I was able to reproduce the bug although it was not with the first user 
leaving, but with the second one. Started researching the matter.

Original comment by volkov.r...@gmail.com on 5 May 2009 at 12:24

[GoogleCodeExporter]

I have studied the problem and found exception when user leaves the room, after 
studying the code I have located the source of it and may describe it here. We 
have 
this piece of code in ScopeApplicationAdapter.java:
First, this.clientListManager.removeClient(currentClient.getStreamid()); is 
called in 
line 292, then we get connections collection and for each connection we find 
its room  
client from the client list manager, BUT! If we leave by exit through 
interface(not 
by closing the browser) there still are connections remained from the old 
client and 
they give the corresponding client id which has already been removed from 
clientlistmanager and the getClientByStreamId function therefore returns null, 
causing NullPointerException when trying to access rcl.getStreamid(). I've 
taken a 
look at different revisions of code and found out that originally 
this.clientListManager.removeClient was AFTER the connections cycle, but in 
rev. 1867 
Sebastian placed it before, as he said, "to workaround the NullPointerException 
in 
the roomLeaveByScope method" :) Well, it aint much of a workaround, I must 
confess, 
since it adds another NullPointerException. I am not the best specialist here 
so I'd 
be glad if Sebastian took a look at this and offered something else to fix the 
NullpointerExceptions. 

Original comment by volkov.r...@gmail.com on 7 May 2009 at 8:35

[GoogleCodeExporter]

Rodion, thank you for this investigation.

Do you have a proposal how to fix this problem? Maybe, there's a plug or 
something to  
have this problem solved in the short-term?

Original comment by e.rovin...@gmail.com on 7 May 2009 at 8:56

[GoogleCodeExporter]

Dear Mr. Rovinsky!
I've investigated the reason further, and found the possible fix for both 
NullPointerExceptions and even more 8) The case is, when a client logs out, the 
work 
of ScopeApplicationAdapter functions takes some time, they talk to clients 
etc., 
etc., but the class itself is not properly synchronized - it only has the 
synchronized keyword on its getInstance method, but this is clearly not enough 
for 
its proper synchronization. So I've added this keyword to every method of it to 
prevent several simultaneous executions at a time, and everything started 
working as 
it should be (note removeClient shifted further, to be _after_ the connections 
cycle). Please take a look at this patch and let me know if everything is ok on 
your 
side.

Original comment by volkov.r...@gmail.com on 7 May 2009 at 2:03

Attachments:

• Scope_Application_Adapter_synchronized.patch

[GoogleCodeExporter]

We've verified.
Works fine now.
Thank you, Rodion.

Original comment by e.rovin...@gmail.com on 26 May 2009 at 2:04

[GoogleCodeExporter]

Patch applied in r2036

Original comment by volkov.r...@gmail.com on 26 May 2009 at 2:17

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by seba.wag...@gmail.com on 29 Aug 2011 at 8:03

• Added labels: Restrict-AddIssueComment-Commit