You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by Maxim Solodovnik <so...@gmail.com> on 2016/09/01 08:18:47 UTC
Re: Requirement to access DB during rendering of conference room
Hello Sebastian,
I believe user list should work better after my today's commits
Could you please check?
On Wed, Aug 24, 2016 at 10:35 AM, Maxim Solodovnik <so...@gmail.com>
wrote:
> BTW Sebastien has modified jquery-ui dialog buttons, so now each has a
> name, you might wand to try to write some UI tests (using wicket tester or
> selenium :)) )
>
> On Wed, Aug 24, 2016 at 10:22 AM, Maxim Solodovnik <so...@gmail.com>
> wrote:
>
>> Some actions can be done on the client only (without roundtrips to the
>> server :) not much of them, but it can easily be done :))
>>
>> On Sun, Aug 21, 2016 at 2:14 PM, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> wrote:
>>
>>> Yeah same here. Even more confusing when I look at it and kind of
>>> remember how it is basically mirroring some of the code and structure that
>>> initially was in the OpenLaszlo client :D
>>>
>>> But overall I think it's pretty cool how less code you can write the UI
>>> with. My only concern with Wicket is that you constantly hold the entire UI
>>> model also on the Server. Which means UI interactions actually create also
>>> load on the server. I think this is a manageable risk. But will be
>>> something we need to be careful with when thinking about scaling this to
>>> large scenarios.
>>>
>>> Another potential modularisation for the future would be to separated
>>> the conference room UI from the admin/profile/settings UI panels. This
>>> would make it easier in the future to plug another conference room UI into
>>> it. And the admin panel does not change that often. While the conference
>>> room, with all the speed at which the UI frameworks change could mean we
>>> got to replace it in a few years again as we might want to use some
>>> specific UI framework that has better support for real-time communication.
>>>
>>> Thanks,
>>> Seb
>>>
>>>
>>>
>>>
>>>
>>> 2016-08-21 14:27 GMT+10:00 Maxim Solodovnik <so...@gmail.com>:
>>>
>>>> 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.wagner@gmail.com <
>>>> seba.wagner@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 <so...@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.wagner@gmail.com <
>>>>>> seba.wagner@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 <so...@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.wagner@gmail.com <
>>>>>>>> seba.wagner@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.wagner@gmail.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> WBR
>>>>>>>> Maxim aka solomax
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sebastian Wagner
>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>> seba.wagner@gmail.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> WBR
>>>>>> Maxim aka solomax
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Wagner
>>>>> https://twitter.com/#!/dead_lock
>>>>> seba.wagner@gmail.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>>>>
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
WBR
Maxim aka solomax
Re: Requirement to access DB during rendering of conference room
Posted by se...@gmail.com.
Will do. I should be able to come back to you in 1-2 days.
Thanks
Seb
Sent from my iPhone
> On 1/09/2016, at 8:18 PM, Maxim Solodovnik <so...@gmail.com> wrote:
>
> Hello Sebastian,
>
> I believe user list should work better after my today's commits
> Could you please check?
>
>> On Wed, Aug 24, 2016 at 10:35 AM, Maxim Solodovnik <so...@gmail.com> wrote:
>> BTW Sebastien has modified jquery-ui dialog buttons, so now each has a name, you might wand to try to write some UI tests (using wicket tester or selenium :)) )
>>
>>> On Wed, Aug 24, 2016 at 10:22 AM, Maxim Solodovnik <so...@gmail.com> wrote:
>>> Some actions can be done on the client only (without roundtrips to the server :) not much of them, but it can easily be done :))
>>>
>>>> On Sun, Aug 21, 2016 at 2:14 PM, seba.wagner@gmail.com <se...@gmail.com> wrote:
>>>> Yeah same here. Even more confusing when I look at it and kind of remember how it is basically mirroring some of the code and structure that initially was in the OpenLaszlo client :D
>>>>
>>>> But overall I think it's pretty cool how less code you can write the UI with. My only concern with Wicket is that you constantly hold the entire UI model also on the Server. Which means UI interactions actually create also load on the server. I think this is a manageable risk. But will be something we need to be careful with when thinking about scaling this to large scenarios.
>>>>
>>>> Another potential modularisation for the future would be to separated the conference room UI from the admin/profile/settings UI panels. This would make it easier in the future to plug another conference room UI into it. And the admin panel does not change that often. While the conference room, with all the speed at which the UI frameworks change could mean we got to replace it in a few years again as we might want to use some specific UI framework that has better support for real-time communication.
>>>>
>>>> Thanks,
>>>> Seb
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2016-08-21 14:27 GMT+10:00 Maxim Solodovnik <so...@gmail.com>:
>>>>> 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.wagner@gmail.com <se...@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 <so...@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.wagner@gmail.com <se...@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 <so...@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.wagner@gmail.com <se...@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.wagner@gmail.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> WBR
>>>>>>>>> Maxim aka solomax
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sebastian Wagner
>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>> seba.wagner@gmail.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> WBR
>>>>>>> Maxim aka solomax
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sebastian Wagner
>>>>>> https://twitter.com/#!/dead_lock
>>>>>> seba.wagner@gmail.com
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> WBR
>>>>> Maxim aka solomax
>>>>
>>>>
>>>>
>>>> --
>>>> Sebastian Wagner
>>>> https://twitter.com/#!/dead_lock
>>>> seba.wagner@gmail.com
>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>
>
>
> --
> WBR
> Maxim aka solomax