>> What about the chat, I have seen you made some changes to the chat lately >> Maxim? Is the Chat in the dashboard now in the database?
I add chat to the DB for Wicket only (only global chat for now with small amount of testing) I had no plans to change it for Flash app On Mon, Feb 4, 2013 at 5:36 AM, seba.wag...@gmail.com <seba.wag...@gmail.com > wrote: > I would like to share the progress in the Cluster API. > For a design overview see: > > https://cwiki.apache.org/confluence/display/OPENMEETINGS/Cluster+Master-Slave+overview > > Status: > The database session cache as alternative to the memory session cache does > work now (with a single server and the serverId commented out in the Spring > config). > So you can configure the Client to be stored in memory or in database via > Spring config. > > What needs to be done: > 1) There are some places in the code where there is a hardcoded "null" for > the serverId. For example when updateing a Client. This was because in a > former iteration of the Cluster API "null" meant the Client is on > "localhost". In the new API, the serverId should be always read from the > org.apache.openmeetings.session.ServerUtil, which then reads it from the > Spring config. > And in the future, when the server is in cluster mode, there is no "null" > used anymore, serverId null simply means that there is no cluster > configured. > It might makes sense to throw an Exception upon startup: > If serverId == null and serverDao.getServers().size() > 0 => throw > Exception(" You have to configure a server for this instance to run the > cluster correctly). > + the serverId in the Spring config should become the "serverAdress" > > 2) There has to be a "clever" clean up job in the client table each time > the server starts up. > Cause what can happen now is: If a server is shut down you still have > entries in the client table. The next time the server is startup, those > clients are of course no more online. But the server does not know. > A simply "delete all" will not work, cause in a cluster you will have > multiple servers writing to the same database, and you can't "delete all" > because some servers might be still online. > So this is a bit tricky. > The idea would be: If the serverId is NULL (meaning no cluster configured) > It is save to delete all records in the clients-table upon server start > If the serverId is NOT NULL (cluster mode), then it you can still clean up: > - All clients with the serverId of the current server starting up > (cause no client can be already connected to a server that just boots) > - All clients that are assigned to a serverId in the tables "servers" > that either does not exist or where the server is flaged as "not active". > - All clients that have a serverId null > > From my point of view those are the most important things for the session. > > The other issue is with the whiteboard. Whiteboard is stored in memory too > (because sync method is involved). > A conference room is always inside the same node of the server. But what > could happen is, that the cluster gives the room upon the next day/meeting > to another server/node in the cluster. > Then the previously written stuff on the whiteboard would be gone (or by > random chance if the same server is taken, you might get the same > whiteboard session object again). > Short story: The whiteboard session must be made configureable to be in > database too. And there has to be some clever trick to have only small > effects to the performance while syncing. > > What about the chat, I have seen you made some changes to the chat lately > Maxim? Is the Chat in the dashboard now in the database? > > Sebastian > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > seba.wag...@gmail.com > -- WBR Maxim aka solomax
