Re: Cluster API status
+++
3) The attribute "pass" in the Server Entity must be FetchType.Lazy and the
insert/update method in the UI/ServerDao must be so modified that the
Server's Entity password is only changed when explicitly set.
Otherwise we would need to create a ServerDTO and use that everywhere where
a Server Entity is send to a client. That would also be the same for the
Wicket UI. We can't send a blank password to the UI.
Sending passwords to the client is a no go. Not even in the admin UI.
Anybody could listen/trace the http traffic and read the passwords (that
are not even MD5 hash'ed cause we need to know it to login from one server
to another, for example to a kick a user in another node in the cluster).
The pass should never be read anywhere. If we need to check the pass or
really need it somewhere we should use a special "JOIN FETCH" query to read
it exceptional).
It will be still a doubt for our future. Storing blank passwords in the
database is just no good idea.
Is there an alternative that we have?
Sebastian
2013/2/4 seba.wag...@gmail.com
> 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
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wag...@gmail.com
Re: Cluster API status
>> 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 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
Re: Cluster API status
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
> >> 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
Re: Cluster API status
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
>
> > >> 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
>
Re: Cluster API status
Vasiliy is currently trying to set up old versions of OM and produce the
backups (He going to send email to you)
On Mon, Feb 4, 2013 at 11:01 AM, seba.wag...@gmail.com <
seba.wag...@gmail.com> wrote:
> 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
>
> > 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
> > >
> > > > >> 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
RE: Cluster API status
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: seba.wag...@gmail.com [mailto:seba.wag...@gmail.com] 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 > 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 > > > > > >> 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-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.getServe
Re: Cluster API status
What about the audio quality? Sebastian 2013/2/4 Irina Arkhipets > 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: seba.wag...@gmail.com [mailto:seba.wag...@gmail.com] > 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 > > > 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 > > > > > > > >> 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-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&
RE: Cluster API status
Quality was OK for call to one external phone number. However I believe we still need additional tests. Regards, Irina. -Original Message- From: seba.wag...@gmail.com [mailto:seba.wag...@gmail.com] 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 > 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: seba.wag...@gmail.com [mailto:seba.wag...@gmail.com] > 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 > > > 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 > > > > > > > >> 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-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 p
