incubator-openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "seba.wagner@gmail.com" <seba.wag...@gmail.com>
Subject Re: [DISCUSS] cluster API - extending the Client with a server attribute
Date Sun, 27 Jan 2013 07:12:26 GMT
No you're right. But actually the clients will connect to a server in the
cluster node based on a calculation that will search for the node that has
the least userload (or where the room is already started). So the
config.xml will be dynamically overwritten and you will be redirecting to
that host/port when you enter the conference room.
So reading those values simply from the config.xml will not work.
However the client already know this "serverId", cause when he redirects to
a node he has the ServerDTO.

But now you would need to add this serverId to every request where the
server manipulates the former "RoomClient" (now
org.apache.openmeetings.persistence.beans.rooms.Client). Because the server
does not know which serverId he his.
And after that you have to add this serverId to every cascading call until
it reaches the "SessionManager" where the serverId is needed.

I am not sure, but that sounds complex compared to adding a configuration
parameter to the applicationContext and simply load that property into the
SessionManager upon server start. Wouldn't it make more sense if the server
instance know who he is without additional info?
You will need to configure the Spring config to change the session(Client
list) to be stored in database and not in memory anyhow. So using only the
Web-UI to configure from single to cluster usage will not work. A restart
of the Tomcat Server to load that config will be required too. But only of
the node that is new in the cluster must need to be restarted. So you can
add new nodes to the cluster without the need for a restart of all.

Sebastian


2013/1/27 Maxim Solodovnik <solomax666@gmail.com>

> I believe there is misunderstanding here.
>
> I see 2 areas:
> 1) admin area is configured by admin and changed not very often.
> 2) client area: we need some mechanism to understand which client is
> currently on which server in cluster.
>
> So I propose the following: admin set up servers in admin section (db
> writes are performed) and set up address in client config.xml.
>
> The client connects to server and can tell any instance where is it came
> from (no sb writes are performed)
>
> Or maybe I'm trying to solve wrong problem? :)
> On Jan 27, 2013 12:14 PM, "seba.wagner@gmail.com" <seba.wagner@gmail.com>
> wrote:
>
>> Admin section is saved to the database.
>> If every instance writes to the same database and table in the cluster
>> you will simply have the same serverId or address in all instances. I might
>> not even theoretically image any solution where an OpenMeetings instance
>> will find out purely on what is written in the database which record in the
>> servers' table it it :)) You always need some meta data from another
>> source. Either host or id or something.
>>
>> The config.xml is for client side configuration. We do not load values
>> from the config.xml to the server side part to do anything. At least we
>> shouldn't :)
>>
>> Sebastian
>>
>>
>> 2013/1/27 Maxim Solodovnik <solomax666@gmail.com>
>>
>>> too complicated questions :)
>>>
>>> I believe any address should be configured in admin section (it should
>>> be unique)
>>> this address should be used instead of id in openmeetings-applicationContext.xml
>>> (of any other file used for configuration)
>>>
>>> the other idea i can come up with:
>>> addional property is added to the config.xml (the address of current
>>> server) this address is passed in case of cluster config and based on the
>>> address server is determined
>>>
>>>
>>>
>>>
>>> On Sun, Jan 27, 2013 at 11:34 AM, seba.wagner@gmail.com <
>>> seba.wagner@gmail.com> wrote:
>>>
>>>> I was thinking about that, but there are several issues with it:
>>>>
>>>> 1) where should this address be taken from? You would need to read it
>>>> from System.getProperties().
>>>> That means you have OS specific stuff in your code. Or you will end up
>>>> in writing this attribute in the some startup script. I would rather then
>>>> configure it in the spring config.
>>>> 2) What if the server has not configured the public host address
>>>> because it is sitting behind some corporate firewall. Internally the host
>>>> might have a different or multiple names.
>>>> 3) What if you have multiple instances running on the same host (okay
>>>> makes no sense from scaling point of view, but testing is more easy if you
>>>> can configure a cluster locally by running 2 instances on the same host
>>>> with different ports)
>>>>
>>>> Sebastian
>>>>
>>>>
>>>> 2013/1/27 Maxim Solodovnik <solomax666@gmail.com>
>>>>
>>>>> Maybe server address might be used instead? (id will be taken from the
>>>>> DB on address basis)
>>>>>
>>>>>
>>>>> On Sun, Jan 27, 2013 at 8:33 AM, seba.wagner@gmail.com <
>>>>> seba.wagner@gmail.com> wrote:
>>>>>
>>>>>> Currently my only idea to implement this is:
>>>>>> We add a property-bean in our spring config where you can configure
>>>>>> the serverId of the current instance.
>>>>>>
>>>>>> In addition to that, you will also have to configure the session
to
>>>>>> be stored in the database instead of memory. From my point of view
that
>>>>>> makes sense. You have the possibility to configure the session to
be in
>>>>>> memory (default) if switching to cluster, you have to edit
>>>>>> openmeetings-applicationContext.xml to use another Bean. I think
that is
>>>>>> comparable to other applications.
>>>>>>
>>>>>> But I am not so sure for the serverId, if
>>>>>> openmeetings-applicationContext.xml is really the right place for
it. But
>>>>>> because of lack of other options I would just use it now.
>>>>>>
>>>>>> Sebastian
>>>>>>
>>>>>>
>>>>>> 2013/1/25 seba.wagner@gmail.com <seba.wagner@gmail.com>
>>>>>>
>>>>>> I simplified the Client object to a single class again:
>>>>>>> org.apache.openmeetings.persistence.beans.rooms.Client
>>>>>>>
>>>>>>> I would like to make it configurable if the Client is stored
in the
>>>>>>> database or in the memory (similar to Tomcat Session handling).
>>>>>>>
>>>>>>> But there is no need to create an Interface. My first idea was
to
>>>>>>> have two "Client" classes (one DB one memory) and use the interface
to hide
>>>>>>> some of the attributes when the object is send to the client.
For example
>>>>>>> the new attribute "id", its just an auto-incrementor of the database,
for
>>>>>>> the client its useless overhead that eats bandwidth.
>>>>>>> However, Red5 does some reflection to lookup attributes, so it
does
>>>>>>> not use the Interface but the concrete class. We will have to
design DTOs
>>>>>>> to make our client server communication more "lean" and performing
better
>>>>>>> in bandwidth.
>>>>>>>
>>>>>>> However my current problem is that we need to add the information
>>>>>>> "server" to each client before we store it to the database. The
streamId
>>>>>>> will be no more unique, each instance of red5 will count its
own
>>>>>>> streamid-count and will produce duplicates.
>>>>>>> Only the combination of streamid + server(id) will be unique.
>>>>>>>
>>>>>>> But how can I find out on which server I am currently?
>>>>>>> We can't add a flag "isCurrent" to the database. As all instances
>>>>>>> write to the same database that flag to be true "everywhere"
:)
>>>>>>> Also adding a config value won't work as every instance will
>>>>>>> overwrite each other.
>>>>>>>
>>>>>>> Any idea or alternative thought on that?
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Sebastian
>>>>>>>
>>>>>>> --
>>>>>>> Sebastian Wagner
>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>> http://www.webbase-design.de
>>>>>>> http://www.wagner-sebastian.com
>>>>>>> seba.wagner@gmail.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sebastian Wagner
>>>>>> https://twitter.com/#!/dead_lock
>>>>>> http://www.webbase-design.de
>>>>>> http://www.wagner-sebastian.com
>>>>>> seba.wagner@gmail.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> WBR
>>>>> Maxim aka solomax
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sebastian Wagner
>>>> https://twitter.com/#!/dead_lock
>>>> http://www.webbase-design.de
>>>> http://www.wagner-sebastian.com
>>>> seba.wagner@gmail.com
>>>>
>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>


-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message