Quality was OK for call to one external phone number. However I believe we still need additional tests.
Regards, Irina. -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Monday, February 04, 2013 11:57 AM To: dev Subject: Re: Cluster API status What about the audio quality? Sebastian 2013/2/4 Irina Arkhipets <[email protected]> > 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] > > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
