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, seba.wag...@gmail.com <
seba.wag...@gmail.com> 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 <solomax...@gmail.com>:
>
>> 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, seba.wag...@gmail.com <
>> seba.wag...@gmail.com> 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 <solomax...@gmail.com>:
>>>
>>>> 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, seba.wag...@gmail.com <
>>>> seba.wag...@gmail.com> 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
>>>>> seba.wag...@gmail.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>>>>
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> seba.wag...@gmail.com
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> seba.wag...@gmail.com
>
--
WBR
Maxim aka solomax
