ok thx, I guess we can also let the dashboard chat untouched. Theoretically there is no need to put it into the database as long as the clients initially always connect to the same node (as we did plan). But the chat history in the conference room needs to be put into the db as it could potentially happen that the next day/meeting the cluster decides to put the room on another node.
Sebastian 2013/2/4 Maxim Solodovnik <[email protected]> > >> 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, [email protected] < > [email protected] > > 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 > > [email protected] > > > > > > -- > WBR > Maxim aka solomax > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
