Mailing-List: contact openmeetings-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: openmeetings-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of seba.wagner@gmail.com
 designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJmbs8gcFexPAiPk4pn3TnU=bb3Gp9OL3qoaTPEK8=+D1UWLtg@mail.gmail.com>
References: 
 <CACeMiA8f5+Rz87S4rODqEF=GMRcjW+EzSzzGAHXjHoNnuaE6Hw@mail.gmail.com>
 <CAJmbs8g+FbiczthL7YNvNijay_hz=nOmfDz-2nsYHKT0Pqi1ew@mail.gmail.com>
 <CACeMiA9MkMQLD9KV8o9TuDFUJQjJziL6EseyvaX2JhCe9W4fjg@mail.gmail.com>
 <CAJmbs8i7Ud3vY9u4tsM+4dfTSSDKqot2N2xxSDeO8NXnWXEoGg@mail.gmail.com>
 <CACeMiA8GnvuC_C7k+fT7JiQNkGHZAz=BSH31FM9sZhvyZ4Bh9g@mail.gmail.com>
 <CAJmbs8gbqD_ingGcoN0Gwv-EU5hesFRXE0-4_j7fZcOBxKmP8g@mail.gmail.com>
 <CAJmbs8j1F1vnePDO7kgZrksAS2xpp9AJvBMqoyq1kurAvJ9cbw@mail.gmail.com>
 <CACeMiA9qgr=orgBqMcAnv8+WDS1ZzYT9XeGi21LaL8Tsc6_VhA@mail.gmail.com>
 <CAJmbs8gcFexPAiPk4pn3TnU=bb3Gp9OL3qoaTPEK8=+D1UWLtg@mail.gmail.com>
From: "seba.wagner@gmail.com" <seba.wagner@gmail.com>
Date: Thu, 1 Nov 2012 16:08:15 +0100
Message-ID: 
 <CACeMiA8FFVQqkgXacEnZFDrwNSwprnUzjN-fETp3s5-Bi8-_xg@mail.gmail.com>
Subject: Re: OpenMeetings in clustering with Master/Slave - Public API Review
To: Maxim Solodovnik <solomax666@gmail.com>
Cc: "openmeetings-dev@incubator.apache.org"
 <openmeetings-dev@incubator.apache.org>
Content-Type: multipart/alternative; boundary=90e6ba10a7dfa4f29f04cd7064b8

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

Yeah,

sorry but you should get comfortable with it :))
Nodes in the cluster have to communicate with each other, so they now "I am
here".
And any communication between nodes should happen via a defined API.
What you want to get rid of I rather see as an enhancement. With the ping
method the master not only knows the userload on all nodes but also which
of the nodes are really online.

I know that in the PHP, Mysql, LAMP world load balancing and clustering is
done by using RSync scripts to sync data between Nodes and making some
MySQL replication. That might be the standard way to cluster and scale
here. And then you do some round rubin as load balancer.
But we are not a PHP, MySQL, LAMP application.

We have caches, we create sequences in all instances that write to the
database. Later on we should implement Transactions, so that we can really
do "RollBack" if for example a User registration fails, so that not part of
the user is written to db while other part isn't.

Ideally in our setup the "slaves" do not need a database at all. They
simply do streaming of audio/video and sync messages between the clients of
a conference room.
Only the master handles db (how we scale/cluster the master is a quite
different story).

What we are doing now is one step in that direction. Make the slave do less
db related stuff until finally slaves will do streaming only.
And finally we can then think about how to apply the existing
Red5-Clustering based on Edge-Orion clustering where the RTMPClient acts a
StreamProxy.

Sebastian


2012/11/1 Maxim Solodovnik <solomax666@gmail.com>

> Sorry forgot we have only 1 db. Trying to invent simplier ways to set up
> cluster (without all those manual syncronisations)
> On Nov 1, 2012 9:31 PM, "seba.wagner@gmail.com" <seba.wagner@gmail.com>
> wrote:
>
>> Sorry I don't understand. What has db-clustering todo with the RPC
>> Gateway now?
>>
>> Sebastian
>>
>>
>> 2012/11/1 Maxim Solodovnik <solomax666@gmail.com>
>>
>>> Maybe db-clustering can be used? Like MySQL supports clustering ...
>>> On Nov 1, 2012 9:25 PM, "Maxim Solodovnik" <solomax666@gmail.com> wrote:
>>>
>>>> Is any soap user can send such ping?
>>>> On Nov 1, 2012 9:10 PM, "seba.wagner@gmail.com" <seba.wagner@gmail.com>
>>>> wrote:
>>>>
>>>>> native Java rpc, I guess you want to serialize the objects to transfer
>>>>> between the instances and transfer via Sockets.
>>>>> As far as I understood we then would need to set up our own
>>>>> SocketListener and need yet another port to communicate between the
>>>>> instances.
>>>>> I am rather afraid of the security flaws that we might open the door,
>>>>> I would rather use the existing RPC Gateways that we have.
>>>>> A simple HTTP Rest call can be quite similar in terms of runtime
>>>>> length.
>>>>> After all, master and slaves do not communicate in "real time". The
>>>>> slaves ping the master every 3 seconds and update their status. So if the
>>>>> call takes 200 milliseconds or 400 milliseconds does not matter at this
>>>>> point.
>>>>>
>>>>> Sebastian
>>>>>
>>>>>
>>>>> 2012/11/1 Maxim Solodovnik <solomax666@gmail.com>
>>>>>
>>>>>> Ah OK. I thought of native Java rpc, but I guess you are right.
>>>>>> Soap/rest looks so heavy :(
>>>>>> On Nov 1, 2012 8:53 PM, "seba.wagner@gmail.com" <
>>>>>> seba.wagner@gmail.com> wrote:
>>>>>>
>>>>>>> What do you mean by RPC?
>>>>>>> REST/SOAP are actually RPC Gateways.
>>>>>>> Also SOAP/REST is our standard RPC Gateway API.
>>>>>>> So what additionally RPC Gateway are you refering to?
>>>>>>>
>>>>>>> If we "open" yet another "door" to interact with OpenMeetings we
>>>>>>> should either make all remote calls that are available via SOAP/REST
>>>>>>> available via that door too (or maybe I did just not understood what you
>>>>>>> mean :))
>>>>>>>
>>>>>>> Sebastian
>>>>>>>
>>>>>>>
>>>>>>> 2012/11/1 Maxim Solodovnik <solomax666@gmail.com>
>>>>>>>
>>>>>>>> Maybe it make sense to use RPC instead of rest/soap? It should be
>>>>>>>> faster. Or speed is not critical?
>>>>>>>> On Oct 30, 2012 4:44 PM, "seba.wagner@gmail.com" <
>>>>>>>> seba.wagner@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> we have been discussing some of the cluster approaches.
>>>>>>>>> I have summarized some graphs and a API descriptions:
>>>>>>>>>
>>>>>>>>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/Cluster+Master-Slave+overview
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>
>


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

--90e6ba10a7dfa4f29f04cd7064b8--