Thanks! 2011/11/20 Maxim Solodovnik <[email protected]>
> OK sure > RoomClient was the part of RoomPoll this is why I have moved it into DB > I will make the fix immediately > > > On Sun, Nov 20, 2011 at 18:23, [email protected] < > [email protected]> wrote: > >> The query should be: >> SELECT RoomClient where room_id = :room_id and isScreenSharing != true >> >> Anyhow, I have to admit that I would really liek to get rid of the >> RoomClient from the database. The RoomClient is a session object. >> Storing session variables in a database is never a good approach. >> If we need to have a caching control over the RoomClient we should use >> something like Ehcache (http://ehcache.org/). >> >> If you need the RoomClient as reference under some circumstances you can >> still store it "on demand", meaning: You persist the RoomClient only if >> there is really something to store that has this RoomClient as reference. >> I don't really understand why you needed it for the poll feature, >> actually also your implementation does delete all roomclients when the room >> is empty (at least I hope so :D otherwise we have another problem :)))). >> So if you delete the RoomClient anyway => what should anybody reference >> this temp RoomClient object if it will be gone again. >> >> So please make the RoomClient a static variable in the again, we will >> have to think about how to really solve it using a caching mechanism but >> using the database as session cache is not working. >> >> >> Sebastian >> >> 2011/11/20 Maxim Solodovnik <[email protected]> >> >>> 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 >>> >> >> >> >> -- >> 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.
