Since the is selection from the DB I will iterate only to get the list of IDs the call sometheng like:
SELECT RoomClient where id IN(...) OK I will implement your logic tonight On Sun, Nov 20, 2011 at 17:45, [email protected] <[email protected]>wrote: > 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] > -- WBR Maxim aka solomax -- 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.
