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
