• Icon: Suggestion Suggestion
    • Resolution: Fixed
    • 2.3
    • None
    • None
    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      In a corporate environment, its important to be able to cluster webapps so that:
      a) it can be deployed on standard appserver farms (which are clustered)
      b) we have redundancy and automatic failover.

      If the application requires a cold standby (as is the case with Jira nd Confluence as they stand), its a major PITA.
      Due to it support priorities to business-critical applications, a application that requires manual fail-over will have a downtime of anything from minutes to hours.

      As I see it the issues are:

      1) Hibernate Caching - can be taken care of at the hibernate level (known solutions: free and not free - customer can choose)
      2) Indexing. If filesystem indexing is essential, then we need some kind of fault-tolerant index synchronisation mechanism. JMS?
      3) confluence.cfg.xml Config file. Can this be pre-edited and deployed in the WAR?
      4) default-formatting.properties Can this be pre-edited and deployed in the WAR?
      5) Custom Velocity templates: Can these be stored in database or via webdav?

            [CONFSERVER-1554] Make Confluence clusterable

            Confluence 2.3 is now clusterable. Not sure why we didn't close this last week!

            Charles Miller (Inactive) added a comment - Confluence 2.3 is now clusterable. Not sure why we didn't close this last week!

            Bob Swift added a comment -

            Unfortunately, there are many different interpretations for "clustering". Best to stick to specific requirements and each organization will have different ones that fit into this category. Here are mine:
            1) High availability (HA) across a WAN. All instances available. When an instance fails, re-route to another instance. Want advantage of better "local" performance.
            2) HA on local environment (like MSCS solution mentioned above) would be useful especially if 1) is not available
            3) Needs to handle Confluence upgrades with minimal downtime. Upgrades are the BIGGEST cause of downtime for Confluence!
            4) Not just for large customers! As more critical data goes into Confluence, downtime (planned and unplanned) is bad even for smaller companies (50-500 users). Please make it affordable for smaller environments too!

            Bob Swift added a comment - Unfortunately, there are many different interpretations for "clustering". Best to stick to specific requirements and each organization will have different ones that fit into this category. Here are mine: 1) High availability (HA) across a WAN. All instances available. When an instance fails, re-route to another instance. Want advantage of better "local" performance. 2) HA on local environment (like MSCS solution mentioned above) would be useful especially if 1) is not available 3) Needs to handle Confluence upgrades with minimal downtime. Upgrades are the BIGGEST cause of downtime for Confluence! 4) Not just for large customers! As more critical data goes into Confluence, downtime (planned and unplanned) is bad even for smaller companies (50-500 users). Please make it affordable for smaller environments too!

            >>It's alvery well having a cluster, but what we want is a replicated database.

            Confluence caches loads of info - without a distributed cache & distributed event mechanism, this wouldnt work...

            We have a very similar requirement (conf instances in NY, LON & TOK)- and if done right, the clustering solution could scale accross the WAN...

            Nick Minutello added a comment - >>It's alvery well having a cluster, but what we want is a replicated database. Confluence caches loads of info - without a distributed cache & distributed event mechanism, this wouldnt work... We have a very similar requirement (conf instances in NY, LON & TOK)- and if done right, the clustering solution could scale accross the WAN...

            FWIW, I have configured Confluence as a managed service in Microsoft Cluster Server (MSCS). This configuration is tested and in production.

            If you're not familiar with the product, MSCS is a failover cluster system that manages resources among multiple physical nodes. When a physical node fails, the applications, IP address/network names, and physical disk resources are moved from the failing machine to a surviving node in the cluster.

            Justin Pitts added a comment - FWIW, I have configured Confluence as a managed service in Microsoft Cluster Server (MSCS). This configuration is tested and in production. If you're not familiar with the product, MSCS is a failover cluster system that manages resources among multiple physical nodes. When a physical node fails, the applications, IP address/network names, and physical disk resources are moved from the failing machine to a surviving node in the cluster.

            Hi Darren,

            We are currently in the early stages of making Confluence clusterable.

            One of the assumptions we have made to help reduce the complexity of this task is that Confluence will be talking to a single database. We do not distringuish between a single database or a distributed database so long as the behaviour is the same. With your master-master setup, will Confluence be able to make that assumption?

            Originally, primary keys were generated by an application level sequence. This has now been changed to Hibernates HiLo ID generator. How does your custom UUID generation differ from this? Will it work with our assumption of a single database?

            Regards,
            -Daniel

            Daniel Ostermeier added a comment - Hi Darren, We are currently in the early stages of making Confluence clusterable. One of the assumptions we have made to help reduce the complexity of this task is that Confluence will be talking to a single database. We do not distringuish between a single database or a distributed database so long as the behaviour is the same. With your master-master setup, will Confluence be able to make that assumption? Originally, primary keys were generated by an application level sequence. This has now been changed to Hibernates HiLo ID generator. How does your custom UUID generation differ from this? Will it work with our assumption of a single database? Regards, -Daniel

            Kango_V added a comment -

            It's alvery well having a cluster, but what we want is a replicated database. We have 2 main officeses: in Swindon, UK and Sanfransisco, US. We'd like to be able to use the same database via a "maste-master" scenario. But, we are not sure the database keys will allow for this.

            For example, which database holds the next key? We have impleneted our own solutions in Hibernate by using UUID PKs. This works extremely well as the database can be replicated anywhere and it all carries on working.

            Your thoughts on this?

            Kango_V added a comment - It's alvery well having a cluster, but what we want is a replicated database. We have 2 main officeses: in Swindon, UK and Sanfransisco, US. We'd like to be able to use the same database via a "maste-master" scenario. But, we are not sure the database keys will allow for this. For example, which database holds the next key? We have impleneted our own solutions in Hibernate by using UUID PKs. This works extremely well as the database can be replicated anywhere and it all carries on working. Your thoughts on this?

            If one where to configure hibernate to run with a clustered cache (JBoss Cache) and one used a centralized disk for the confluence web app, indexes, etc. Does anyone think that there would be any concurrency issues with disk access? Assuming everything is pointing to a single db, a single file system, and that sessions are sticky (a user always goes to the same machine) would there be other issues? I am going to see if I can get a test environment set up on my end. Has anyone else tried such a setup?

            -paddy

            Padraic Hannon added a comment - If one where to configure hibernate to run with a clustered cache (JBoss Cache) and one used a centralized disk for the confluence web app, indexes, etc. Does anyone think that there would be any concurrency issues with disk access? Assuming everything is pointing to a single db, a single file system, and that sessions are sticky (a user always goes to the same machine) would there be other issues? I am going to see if I can get a test environment set up on my end. Has anyone else tried such a setup? -paddy

            kgbvax added a comment -

            >then, well, it MUST be GOOD!
            Intresting point.
            We deploy Confluence only into Enterprises (5000+). Although they are most of the the time paranoid of putting the least importent apps on hughe whathaveyou clusters, for Wikis it's pretty much a "don't care".

            The pricing helps a lot (as its basically 'nothing'). Sometimes it even get's in the way. People are not used to these numbers. They think it's the maintenance feed
            I agree that it should be raised for "Enterprises" but only to a level which is easily acceptable. 40$/user is OK for a small company or department that 'knows what they are buying' and have a good understanding of th value. Enterprises are mostly driven by a few early adopters who have set up "black ops" OSS wikis in projects/departments. Or somebody read about the Wiki/Blog hype. Keep the pricing like it is, but extend the top end and don't overshoot as this will reduce adoption. Maybe a 10K$ won't harm for 1000 users. Or 2K$ for "unlimited"?

            I guess that will change a year from now when an Enterprise with then relies on a tool like Confluence sees a box die and hundres or more users look at a blank screen.
            Anyway, support for high-end infrastructure may help to differntiate from free (as in beer) implementations.
            The same holds true for auditing (another request).

            kgbvax added a comment - >then, well, it MUST be GOOD! Intresting point. We deploy Confluence only into Enterprises (5000+). Although they are most of the the time paranoid of putting the least importent apps on hughe whathaveyou clusters, for Wikis it's pretty much a "don't care". The pricing helps a lot (as its basically 'nothing'). Sometimes it even get's in the way. People are not used to these numbers. They think it's the maintenance feed I agree that it should be raised for "Enterprises" but only to a level which is easily acceptable. 40$/user is OK for a small company or department that 'knows what they are buying' and have a good understanding of th value. Enterprises are mostly driven by a few early adopters who have set up "black ops" OSS wikis in projects/departments. Or somebody read about the Wiki/Blog hype. Keep the pricing like it is, but extend the top end and don't overshoot as this will reduce adoption. Maybe a 10K$ won't harm for 1000 users. Or 2K$ for "unlimited"? I guess that will change a year from now when an Enterprise with then relies on a tool like Confluence sees a box die and hundres or more users look at a blank screen. Anyway, support for high-end infrastructure may help to differntiate from free (as in beer) implementations. The same holds true for auditing (another request).

            I have been looking for a good java based wiki platform and stumbled upon confluence. However, in our production environment we require full scale aware applications and H/A support. Are there plans to implement these features soon? If not could they be implemented as part of a professional service contract?

            thanks
            Padraic Hannon

            Padraic Hannon added a comment - I have been looking for a good java based wiki platform and stumbled upon confluence. However, in our production environment we require full scale aware applications and H/A support. Are there plans to implement these features soon? If not could they be implemented as part of a professional service contract? thanks Padraic Hannon

            I am not sure I am of the school of thought that confluence needs to be more expensive.

            However, there are simple things that could be done to make it possible to run confluence in a cluster.
            Most are not difficult or complex at all.
            Most I have suggested above.

            If clustering confluence was just a matter of plugging in a distributed cache into hibernate (ie all of the other impediments were solved), then I think that most customers who wanted to cluster confluence would be happy to plug in a 3rd party product like coherance if that was what was required (or use an open source one if it did what they wanted).

            Nick Minutello added a comment - I am not sure I am of the school of thought that confluence needs to be more expensive. However, there are simple things that could be done to make it possible to run confluence in a cluster. Most are not difficult or complex at all. Most I have suggested above. If clustering confluence was just a matter of plugging in a distributed cache into hibernate (ie all of the other impediments were solved), then I think that most customers who wanted to cluster confluence would be happy to plug in a 3rd party product like coherance if that was what was required (or use an open source one if it did what they wanted).

              Unassigned Unassigned
              3b1ae0ec93c9 Nick Minutello
              Votes:
              50 Vote for this issue
              Watchers:
              17 Start watching this issue

                Created:
                Updated:
                Resolved: