Returning a Set<RoomClients> based on the a list of streamid ... you would need to collect all streamids and iterate two times to the clients and a third time to get the RoomCLient from the Set then .... I would not do that.
*1 Basic approach* Those sync methods => they will always iterate through all clients of ONE room ... so you can get those RoomClient BEFORE you iterate through the connections ... and you return a java.util.Map with the streamid as key, so that you can access those RoomClients fast public Map<RoomClient> getRoomClientsByRoomId I still think it would perform better to have no Select at all, however ... doing like that would result in just a single select so I guess we could give it a try. *1A => Extend that basic approach with isScreenClient * This could be a basic solution. But additionally those sync methods always check for one attribute right now: rcl.getIsScreenClient() != null && rcl.getIsScreenClient() => because if the RoomClient is a ScreenSharing Connection => we of course don't want to send this client a whiteboard object! So the method should be: public Map<RoomClient> getRoomClientsForWhiteboardByRoomId(Long roomId) => and only return those clients where isScreenClient != true And in the iteration you need to check if the returning Map containKey(streamid) => to verify we don't send the wrong connection our objects to *1B => Extend that basic approach with upcoming audio/video components* German & Timur's solution with separated Audio/video components will have another effect: We will have two Connections to each Flash client, but we want ONLY ONE to send our whitbeoard objects to. So in a later extension the method: public Map<RoomClient> getRoomClientsForWhiteboardByRoomId(Long roomId) Has to do a SELECT where it only returns those RoomClients that are really the "main-netconnection". 1 + 1 A should be done right now, 1 B is something we can do in a second step. Of course it might be needed in some circumstances to think about if it makes sense to have also the ScreenSharing clients in the returning Map, but the standard use-case will be NOT to have them. Sebastian 2011/11/20 Maxim Solodovnik <[email protected]> > Hello Sebastian, > > I haven't test so much clients, I have no server with big number of > attendees. > To resolve the issue I can write a method in clientListManager which will > accept Set<IConnection> as a parameter and return all roomClients with ids > passed in one request. > > Or if you feel this would be performance degradation I can move RoomClient > out of database. > It was necessary bacause in old designs RoomPolls has references to > RoomClient, currently it references Users, so it might me easily removed > from the DB and will affect nothing. > > > On Sun, Nov 20, 2011 at 16:46, [email protected] < > [email protected]> wrote: > >> Hi Maxim, >> >> I would like to discuss a design problem of the new architecture to store >> the RoomClients in the database. >> >> Did you see that when iterating through the connections for example in >> the method: >> >> http://code.google.com/p/openmeetings/source/browse/trunk/singlewebapp/src/app/org/openmeetings/app/remote/red5/ScopeApplicationAdapter.java#2504 >> >> You request on each connection, everytime you iterate throuhg a SINGLE >> SELECT on the database to get the roomclient ?! >> Meaning if you have 200 people in a conference room you make 200 single >> select statements on the database, and as that happens for example for each >> time the green dod in video-views starts or stops to blink, or each time >> the users sends a new whiteboard event ...actually everytime you sync >> ANYTHING to your participants the server will iterate through all session >> objects and then does now a SINGLE query for each connection getting the >> corresponding RoomClient from the DB. >> >> Did you ever test the effect when having lets say 500 participants >> online, and 150 in a single room and now you send a whiteboard event, how >> long does it take?! I mean we make a real-time application? This >> implementation does not scale at all. That was the reason why the >> RoomClient was a static variable of type HashMap and not in the database. >> To be able to access it really FAST. Red5 does something similar for >> "sharedObjects" it stores them in the session (using ehCache I think). >> >> However, there is really need for immediatelly change in that part, >> making a single selct ON EACH CONNECTION => this will not fly! >> >> Can you please propose some concept on that, so we discuss this together >> and then implement it. >> >> >> Sebastian >> >> -- >> Sebastian Wagner >> http://www.openmeetings.de >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> [email protected] >> > > > > -- > WBR > Maxim aka solomax > -- Sebastian Wagner http://www.openmeetings.de http://www.webbase-design.de http://www.wagner-sebastian.com [email protected] -- You received this message because you are subscribed to the Google Groups "OpenMeetings developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/openmeetings-dev?hl=en.
