No problem, solving caching issues with our Session Objects will be on our RoadMap for the future. I have experimented with Ehcache, its actually pretty easy.
Sync and update SVN I made some changes too. There is still something todo: At: http://code.google.com/p/openmeetings/source/browse/trunk/singlewebapp/src/app/org/openmeetings/app/remote/red5/ScopeApplicationAdapter.java#2634 There is still a Select on the database in every sync request to get the configuration key: "show.whiteboard.draw.status". This should be eleminated. Can you put the "show.whiteboard.draw.status" in some cache/session variable? There is no need to request this Config from the DB everytime you sync something. You just need to make sure that its initialized when you start the server and updated everytime you do save/update/delete the config key. Also see this new method call that I made to get a config key: cfgManagement.getConfValue(CONF_KEY, typeObject, defaultValue) So your call would be simply: String showDrawStatusAsString = cfgManagement.getConfValue("show.whiteboard.draw.status", String.class, "0"); I guess you could even experiment by directly casting to Boolean: Boolean showDrawStatus = cfgManagement.getConfValue("show.whiteboard.draw.status", Boolean.class, "0"); But I don't know if and how Java does cast 0 / 1 String as Boolean ... in databases 0 and 1 get true and false. However the important Bit is that this DB-Select query is not done at every synchronization between clients. Sebastian 2011/11/20 Maxim Solodovnik <[email protected]> > 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 > -- 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.
