I planned to put both global and room chat into DB for Wicket. I believe we should release what we already got and move to the HTML5 development :)
On Mon, Feb 4, 2013 at 10:43 AM, seba.wag...@gmail.com < seba.wag...@gmail.com> wrote: > 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 <solomax...@gmail.com> > > > >> 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 > > > > > > -- > 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
