Hi Sebastian, Regarding the SIP integration: currently outcome calls work as expected for us and there are still problems with the income calls to the room. It seems like this does not work because of some Asterisk configuration problem. I hope it will be resolved in a couple of days.
Best regards, Irina. -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Monday, February 04, 2013 11:01 AM To: dev Subject: Re: Cluster API status I would vote to have the backups tested. We will dis-attract a lot of people if their backups won't import from old versions. I guess a number of people will try to update if they see that OpenMeetings is now Top Level Project. Also the SIP integration seems to be of greatest interest but there are a lot of people struggling with it. Is SIP production ready? Did you run a test with Irina? Can we do a test call somewhere? Same for cluster, its not production ready yet, so we would need to remove that feature from the website. And then the SWF11 issue with AEC, there are some modifications in the build process needed to get a SWF11 app with AEC enabled. SIP and cluster feature could potentially simply removed from our feature list. That would give more time to verify its production readiness. AEC feature is also requested but OpenMeetings would be at least possible to upgrade from previous versions without that feature. But backup feature is essential to release from my point of view. The worst case scenario for me is if somebody updates, backup fails and they decide to "OpenMeetings is too unstable" and switch back to old version (or not use it at all). We can see already some mails like that poping up in the mailing list because of our semi documentated features. Sebastian 2013/2/4 Maxim Solodovnik <[email protected]> > 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, [email protected] < > [email protected]> 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 <[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-Slav e+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] > > > > > > -- > WBR > Maxim aka solomax > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
