The fix is ready and checked into SVN. sorry for inconvenience :( On Sun, Nov 20, 2011 at 18:26, [email protected] <[email protected]>wrote:
> 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] > -- 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.
