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 05:14:06 GMT
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

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