|
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. 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). 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 >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 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. 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 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? 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, 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. >>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... 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! Confluence 2.3 is now clusterable. Not sure why we didn't close this last week!
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Closed
Major
Make Confluence clusterable
Honestly – I'd recommend renaming the Enterprise edition to "Large Business" and setting the user limit at 1000 ($40/seat) ...because frankly, it isn't Enterprise level. 
Honestly – I'd recommend renaming the Enterprise edition to "Large Business" and setting the user limit at 1000 ($40/seat) ...because frankly, it isn't Enterprise level.
BTW – The pricing, frankly, is screwed up too – Enterprise to me means 5,000 or more users. So the little guy spending $2,200 for 50 users is getting screwed because the 5,000 (or 50,000) user "Enterprise" essentially gets the unlimited licenses for super cheap peanuts per user. And the irony is that they can afford to pay thousands more!
And without clustering, the perception is that any product will start to have performance issues after users load gets above some arbitrary number.
Please note that I didn't say Confluence WILL have perf issues, just that perception of the Pointy Haired Boss is that "Enterprise" means X thousand users will "require clustering" and without that, the product can't possibly scale. But if it costs $XXX,XXX and says "cluster" – then, well, it MUST be GOOD!
Cheers - Timo
P.S. All comments above are my personal opinions – my employer doesn't have [nor want] anything to do with them.