incubator-openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: [DISCUSS] cluster API - extending the Client with a server attribute
Date Sun, 27 Jan 2013 01:33:56 GMT
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.


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!/dead_lock

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