incubator-openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Solodovnik <>
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, <> 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 <>
> 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
> --
> Sebastian Wagner

Maxim aka solomax

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