Thanks I will try to update some demo server with the code by tomorrow. Sebastian Am 20.11.2011 18:05 schrieb "Maxim Solodovnik" <[email protected]>:
> 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.
