incubator-openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Solodovnik <solomax...@gmail.com>
Subject Re: [DISCUSS] cluster API - extending the Client with a server attribute
Date Sun, 27 Jan 2013 04:39:20 GMT
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

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