Mailing-List: contact openmeetings-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: openmeetings-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of solomax666@gmail.com designates
 209.85.210.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACeMiA_8wOL=eke_89QdmN3b8QowMhxF-Yg+dB_WO-d8aXXJpQ@mail.gmail.com>
References: 
 <CACeMiA9L0OoyOQPykaF41RiaWMQKOY8jDRniZE9EqXm-MxtqHg@mail.gmail.com>
	<CACeMiA9yHHRUmM34MqnRXyjZD=hrHMJXEux9eB=ksPHNdYU5KQ@mail.gmail.com>
	<CAJmbs8ixoZYpPs8cKyxhCvJaJ-kZ0hzK6ZjVCZwYyKmkzCJCOg@mail.gmail.com>
	<CACeMiA8U9M2zgm0+o5wyR7s4vJtYt-YT_eAMiW3wSMkR6JUkkg@mail.gmail.com>
	<CAJmbs8iwYnS+uP7ZzmuM-CDoBcrHB5c1JOt2DM1i4C+EmmNhjw@mail.gmail.com>
	<CACeMiA_8wOL=eke_89QdmN3b8QowMhxF-Yg+dB_WO-d8aXXJpQ@mail.gmail.com>
Date: Sun, 27 Jan 2013 13:34:00 +0700
Message-ID: 
 <CAJmbs8hp3VO68p0MfTgaJgs8VKrQrT26eYWKUS3UBLL7DC3e8A@mail.gmail.com>
Subject: Re: [DISCUSS] cluster API - extending the Client with a server
 attribute
From: Maxim Solodovnik <solomax666@gmail.com>
To: seba.wagner@gmail.com
Cc: openmeetings-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=047d7b33d19a97cec004d43f5808

--047d7b33d19a97cec004d43f5808
Content-Type: text/plain; charset=UTF-8

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
>

--047d7b33d19a97cec004d43f5808--