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 seba.wagner@gmail.com
 designates 74.125.82.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJmbs8ixoZYpPs8cKyxhCvJaJ-kZ0hzK6ZjVCZwYyKmkzCJCOg@mail.gmail.com>
References: 
 <CACeMiA9L0OoyOQPykaF41RiaWMQKOY8jDRniZE9EqXm-MxtqHg@mail.gmail.com>
 <CACeMiA9yHHRUmM34MqnRXyjZD=hrHMJXEux9eB=ksPHNdYU5KQ@mail.gmail.com>
 <CAJmbs8ixoZYpPs8cKyxhCvJaJ-kZ0hzK6ZjVCZwYyKmkzCJCOg@mail.gmail.com>
From: "seba.wagner@gmail.com" <seba.wagner@gmail.com>
Date: Sun, 27 Jan 2013 17:34:33 +1300
Message-ID: 
 <CACeMiA8U9M2zgm0+o5wyR7s4vJtYt-YT_eAMiW3wSMkR6JUkkg@mail.gmail.com>
Subject: Re: [DISCUSS] cluster API - extending the Client with a server
 attribute
To: Maxim Solodovnik <solomax666@gmail.com>
Cc: "openmeetings-dev@incubator.apache.org"
 <openmeetings-dev@incubator.apache.org>
Content-Type: multipart/alternative; boundary=f46d043890458f86f904d43dae4d

--f46d043890458f86f904d43dae4d
Content-Type: text/plain; charset=ISO-8859-1

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

--f46d043890458f86f904d43dae4d--