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 -- 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.
