done On Sun, Nov 20, 2011 at 19:49, [email protected] <[email protected]>wrote:
> 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] > -- 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.
