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:21:37 GMT
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

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