by design client is being created in websocket.onConnect method and being destroyed in websocket.onDisconnect (something like this) I'll try to double check all this on all steps Then can fix, and/or describe :) I wrote this loooong time ago, need to refresh my memories :)
On Sun, Aug 21, 2016 at 11:24 AM, [email protected] < [email protected]> wrote: > Hi Maxim, > > yeah I understand, I think those steps: > > 1) change right for the particular user > 2) send rightUpdated event > 3) each user will update their list with the data from server Hashmap > > When you say (3) "each user will update their list" => You mean the > visible user list right? Cause that part is done. > > => And the rest too. It seems like the issue with (1) is that it does not > change the right in the RoomPanel.getClient() [which links through to > the MainPage.client]. > It seems a bit strange as you request the entire list from getRoomClients and > the flag seems to be correctly there. > > I think this is also the issue when you leave the room and re-enter. It > kind of assumes you still have all the rights from the previous session as > the MainPage.client was not reset when you leave and enter to the defaults. > > Thanks, > Seb > > > 2016-08-21 14:05 GMT+10:00 Maxim Solodovnik <[email protected]>: > >> All clients are being stored in huge hashMap on the server >> the idea was >> 1) change right for the particular user >> 2) send rightUpdated event >> 3) each user will update their list with the data from server Hashmap >> I'll double check this next week >> >> On Sun, Aug 21, 2016 at 10:57 AM, [email protected] < >> [email protected]> wrote: >> >>> I understand that you want to get a stable version out. So performance >>> is second priority. But you agree to the maths? It's quite obvious to me >>> that you will run into issues with large number of users with that >>> approach. Especially since the re-rendering of the user list happens on >>> every right change too. It will re-render the list on every participant >>> change. Not just when a new user arrives in the room. >>> >>> Btw the issue in the user list when the "actions" panel doesn't become >>> visible: My use case is: Moderator clicks on the "Grant moderation to >>> client xyz" button in the user list. Then on the receiving end, the status >>> light changes but the actions panel is not there (not on hover, cause the >>> actions-div is missing) >>> >>> And I think the main issue here is that when this event is propagated to >>> each client, all you send at the moment is RoomMassage("rightUpdated"). >>> However, this will not update actually the "Right" on the receiving end. It >>> just re-renders the user list by calling "populateItem' but when the >>> populate runs through the list: >>> >>> actions.setVisible(room.getClient().hasRight(Right.moderator)); >>> >>> room.getClient().hasRight(Right.moderator)=> is still false >>> >>> cause it has actually never been updated on each participant. >>> >>> The status light changes from green to red. But that is because this >>> compares the right to the ListItem<Client> item, not the "current" >>> RoomPanel::getClient() >>> >>> If you look at the Flash/ScopeApplicationAdapter version, it actually >>> always sends around the entire "client" object. The reason for that was >>> that it is really complicated to figure out which attribute has changed and >>> then write a custom code for each attribute change. >>> >>> I think that part is missing yet for the Wicket/HTML version. >>> >>> It seems to me we would need to add either the Client or the Set<Right)> >>> to the RoomMessage and pass that around + update on the receiving end. >>> >>> What do you think? >>> >>> Thanks, >>> Sebastian >>> >>> >>> 2016-08-21 13:18 GMT+10:00 Maxim Solodovnik <[email protected]>: >>> >>>> Thanks for the pointer, >>>> but so fat I see no performance degradation >>>> I'll optimize things as soon as any issues will arise >>>> >>>> currently flash room is unable to hold more than 10 people (according >>>> to one of the user report) >>>> >>>> On Sun, Aug 21, 2016 at 8:35 AM, [email protected] < >>>> [email protected]> wrote: >>>> >>>>> Hi Maxim, >>>>> >>>>> I have seen an example where we store the firstname/lastname in the >>>>> database instead of the session of the "Client". >>>>> >>>>> RoomClientPanel.java::43 >>>>> >>>>> User u = getBean(UserDao.class).get(c.getUserId()); >>>>> >>>>> Just please keep in mind that access the database is always expensive. >>>>> It's not really suited for our real-time communication conference room. >>>>> For >>>>> instance if there are 500 users in a room you have 500 times a select >>>>> user.* from users where id = xyz. And that is for every user that enters >>>>> the room. >>>>> >>>>> So 5 users entering with 500 users in the room = 5x500 = 2500 select >>>>> queries. >>>>> >>>>> 100 users entering with 200 users in the room = 100 x 200 = 20000 >>>>> selection queries. >>>>> >>>>> Just for entering the room. >>>>> >>>>> It's just like one of those lessons learnt from past OpenMeetings >>>>> implementations: >>>>> Do not access the database during the real-time communication part of >>>>> a conference room. It just doesn't scale. >>>>> Session vars should be really in the session, not in the database. >>>>> >>>>> But it's really more generic: The real-time communication tasks like: >>>>> userlist, activities, whiteboard events => There should be really no link >>>>> from those components into the Database. And if so you have to be really >>>>> careful to make it not interrupting, async and the impact of scaling with >>>>> 500++ users in a conference room. >>>>> >>>>> Thanks, >>>>> Sebastian >>>>> >>>>> -- >>>>> Sebastian Wagner >>>>> https://twitter.com/#!/dead_lock >>>>> [email protected] >>>>> >>>> >>>> >>>> >>>> -- >>>> WBR >>>> Maxim aka solomax >>>> >>> >>> >>> >>> -- >>> Sebastian Wagner >>> https://twitter.com/#!/dead_lock >>> [email protected] >>> >> >> >> >> -- >> WBR >> Maxim aka solomax >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > [email protected] > -- WBR Maxim aka solomax
