Just look through the new design It seems to be very similar to the old one :) With the only major exception: It uses OpenJPA special driver to avoid DB conflics :)
great :) On Wed, Jan 16, 2013 at 1:21 AM, [email protected] < [email protected]> wrote: > Gliffy, its part of our wiki (Add => Gliffy) > > Sebastian > > > 2013/1/16 Alexei Fedotov <[email protected]> > >> Sebastian, >> which tool do you use to create such good looking pictures? >> >> -- >> With best regards / с наилучшими пожеланиями, >> Alexei Fedotov / Алексей Федотов, >> http://dataved.ru/ >> +7 916 562 8095 >> >> >> On Tue, Jan 15, 2013 at 5:31 AM, [email protected] >> <[email protected]> wrote: >> > PS: Get well soon :) >> > >> > >> > 2013/1/15 [email protected] <[email protected]> >> > >> >> I guess Wicket will use the standard Tomcat session handling. >> >> Tomcat itself uses the same approach (in-memory, database or >> file-based) >> >> for clustering >> >> as we do. But of course it has some more advanced technologies to >> >> synchronize and configure as well as its more reliable then doing >> something >> >> from scratch. >> >> >> >> Sebastian >> >> >> >> >> >> 2013/1/15 Maxim Solodovnik <[email protected]> >> >> >> >>> I believe Wicket supports clustering. Maybe we can use Wicket session? >> >>> >> >>> I'll try to review design ASAP (I'm a little bit sick right now, might >> >>> take some time) >> >>> On Jan 15, 2013 8:21 AM, "[email protected]" < >> [email protected]> >> >>> wrote: >> >>> >> >>>> Hi Maxims, >> >>>> >> >>>> please review again, I changed it even more. >> >>>> >> >>>> This SOAP/REST sync between nodes is really not good. It will be much >> >>>> too slow. >> >>>> A lightweight session object in the database as you proposed >> initially >> >>>> is better. >> >>>> That way every node in the cluster has a lightweight (but clustered) >> >>>> session store available and can redirect the user to the correct >> node (and >> >>>> we have no cluster specific code in our app). >> >>>> >> >>>> Also that way we can use a DNS load balancing as like any other web >> >>>> application and our HTTP traffic is clustered. Not only RTMP. >> >>>> I think this approach more meets the real world. >> >>>> >> >>>> Sebastian >> >>>> >> >>>> >> >>>> >> >>>> 2013/1/15 Maxim Solodovnik <[email protected]> >> >>>> >> >>>>> Hooray :) less components is better :) >> >>>>> On Jan 15, 2013 7:39 AM, "[email protected]" < >> >>>>> [email protected]> wrote: >> >>>>> >> >>>>>> I have updated the graph for the cluster architecture: >> >>>>>> >> >>>>>> >> https://cwiki.apache.org/confluence/display/OPENMEETINGS/Cluster+Master-Slave+overview >> >>>>>> >> >>>>>> The biggest change is that master and slave have the same database >> (or >> >>>>>> database-cluster). That makes it a lot easier. >> >>>>>> The master will still need to coordinate the load, so he needs to >> ping >> >>>>>> all slaves to collect the load and redirect to the slave that has >> the least >> >>>>>> traffic (or that actually already hosts the requested room) >> >>>>>> However the slaves can handle both HTTP and RTMP traffic. There is >> no >> >>>>>> need to separate that anymore as the slave would use the same >> database as >> >>>>>> the master. >> >>>>>> >> >>>>>> For syncing the recordings and other files to the master HDD there >> are >> >>>>>> multiple solutions. One would be like Maxim proposed to do a Samba >> mount. >> >>>>>> The other is for example to use some RSync scripts. This can be >> >>>>>> decided by the end user on its own. >> >>>>>> >> >>>>>> I think this is more suitable then the previous approach and uses >> the >> >>>>>> standard mechanisms for clustering. >> >>>>>> >> >>>>>> Let me know what you think about that. >> >>>>>> >> >>>>>> Thanks! >> >>>>>> Sebastian >> >>>>>> >> >>>>>> -- >> >>>>>> 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] >> >>>> >> >>> >> >> >> >> >> >> -- >> >> 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] >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected] > -- WBR Maxim aka solomax
