If several people join a meeting at the same time, they can end up in different meetings

[GoogleCodeExporter]

If several people join a meeting at the same time, they can end up in different 
meetings. 
The meeting ID sent to tomcat is the same ID, but they can get assigned 
different internal meeting IDs.

When this happens, the tomcat servlet prints these errors: 
2012-06-21 18:02:52,533 WARN [org.bigbluebutton.api.MeetingService] - <The 
meeting 9a70776c743352cfcf688e52512673332e5e4007-1340318748362 doesn't exist> 
2012-06-21 18:05:49,319 WARN [org.bigbluebutton.api.MeetingService] - <The 
meeting 9a70776c743352cfcf688e52512673332e5e4007-1340318962908 doesn't exist>

We can reproduce this error fairly often by having three people join a meeting 
at nearly the same time.

Each joiner performs the following steps: 
Create Meeting [ID=nnn] 
Join Meeting [ID=nnn] 
So it is possible to have several create requests arriving at the tomcat 
servlet at nearly the same time.

If the joiners do not join in quick succession, then things work fine.

Original issue reported on code.google.com by ritza...@gmail.com on 27 Jan 2014 at 4:49

[GoogleCodeExporter]

We found two ways to reproduce similar errors with meeting sessions:

1) Late joiner 
-- If the create and then join meeting APIs are called, and then the client is 
slow to load the SWFs, 
the Tomcat process can remove the meeting from its list of active meetings ( 
defaultMeetingCreateJoinDuration timer). If Tomcat removes the meeting, and 
then the SWFs are 
loaded, they seem to start fine, but Tomcat has no knowledge of the meeting.

2) Rejoin an ended meeting 
-- If all attendees in a meeting leave, Tomcat retains the meeting for a period 
of time (defaultMeetingExpireDuration timer). 
Even if this parameter is set to zero, Tomcat will retain the meeting in memory 
for a while. Usually 
it is less than a minute, but we have seen it be longer once. If an attendee 
rejoins the meeting 
while Tomcat sees the meeting in this final-shutdown stage (still existing, but 
no attendees), then 
the attendee can load its SWFs and think he is in a valid meeting, but Tomcat 
eventually removes 
the meeting from memory. At this point there is a meeting running, but Tomcat 
doesn't think there is one.

Original comment by ritza...@gmail.com on 27 Jan 2014 at 4:49