geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Dillon" <>
Subject Re: Why Confluence cannot not be used as a wiki, and how it mightbe fixed
Date Sat, 04 Feb 2006 05:45:53 GMT
I will belive it when I see it. 

In the mean time, changing the layout not to render user specific mumbo jumbo by default should
take care of 90% of the problem. 


-----Original Message-----
From: Hernan Cunico <>
Date: Fri, 03 Feb 2006 22:45:23
Subject: Re: Why Confluence cannot not be used as a wiki, and how it might
 be fixed

In terms of performance, Atlassian team is working on a "Confluence Massive" that will run
in a 
cluster. That should not only address performance but also high availability.
Does anybody have more details on this?


Aaron Mulder wrote:
> I'm not sure how to interpret this; are Ken/Noel suggesting that we
> should stop using Confluence for the time being, or just that there
> are more obstacles to get it fully implemented than were initially
> expected?
> Thanks,
>     Aaron
> On 2/3/06, Rodent of Unusual Size <> wrote:
>>Forwarding to the dev@ list with permission.  This
>>is where it belongs.
>>#ken    P-)}
>>Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
>>Author, developer, opinionist      http://Apache-Server.Com/
>>"Millennium hand and shrimp!"
>>---------- Forwarded message ----------
>>From: "Noel J. Bergman" <>
>>To: "Hernan Cunico" <>, <>
>>Date: Fri, 3 Feb 2006 10:08:19 -0500
>>Subject: Why Confluence cannot not be used as a wiki, and how it might be fixed
>>To quote Atlassian: "Confluence will likely die if slashdotted, so shouldn't
>>be used as a *primary* project website if slashdotting is likely."  Read
>>"slashdotting" as heavy load, and we experience sufficient load on the Wiki
>>to make caching mandatory.
>>The comment:
>> "The main problem with the reverse-proxy solution is that every
>>  Confluence page is built dynamically for whichever user is
>>  currently accessing it."
>>is a typical indicator of a common problem in many dynamic content systems,
>>which all too often neglect the fact that 99.999+% of all traffic is going
>>to be relatively static and anonymous.  Dynamic does not mean ephemeral, and
>>that distinction is missed all too often.
>>The facts are that most Wiki access is anonymous, and Wiki content is almost
>>entirely static and should be cachable.  Confluence intentionally breaks
>>caches, and that behavior needs to be fixed.  There are a number of possible
>>One way, and just a simple one, since there are others, would be for
>>anonymous and authenticated access could have different URLs, e.g.,
>>mydomain.tld/confluence/anon/ for the public, and
>>mydomain.tld/confluence/auth/ for authenticated users.  That would permit
>>the vast majority of accesses to be cached.  "WAIT", you say, "What about
>>when someone edits the page under the /auth/ path?  Won't that cause a
>>problem for viewers in the /anon/ path?"  Not if the URLs are properly
>>designed, and the system is supporting Conditional Get.  The /anon/ path
>>should be handling Conditional Get based upon the timestamp of the page
>>resource.  So most GET requests will simply return 304, unless the page has
>>been changed, in which case the updated resource can be returned and cached.
>>So these are technical issues (Joshua Slive outlined other, related, ones),
>>and the ball has been in Atlassian's court to provide some resolution.
>>        --- Noel

View raw message