Mailing-List: contact jspwiki-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-user@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <49DC7C22.6070800@turton.co.za>
Date: Wed, 08 Apr 2009 12:27:46 +0200
From: Trevor Turton <trevor@turton.co.za>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: jspwiki-user@incubator.apache.org
Subject: Re: JspWiki in clustered environment
References: <cb4334c30904070806iccc3233sbd865a3c5a73fe5f@mail.gmail.com>
 <720BC25B-1696-46D5-9FD2-26463D6400DE@ecyrd.com>
In-Reply-To: <720BC25B-1696-46D5-9FD2-26463D6400DE@ecyrd.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

While you're talking about the question of performance, may I suggest 
that JSPWiki could gain substantial performance benefits by using 
RESTful principles?  (See http://en.wikipedia.org/wiki/REST).  I hasten 
to add that JSPWiki's performance is plenty good enough for me, I have a 
closed membership of only 2,000 or so people to service.  But if the 
JSPWiki development community decides that it needs to handle really big 
volumes then you could refactor the URLs that they conform to the REST 
approach.  So for example where the URL might currently look like 
http://bigwiki.org/Wiki.jsp?page=SomePage to read SomePage, or 
http://bigwiki.org/Edit.jsp?page=SomePage to get an editable copy, or 
http://bigwiki.org/Delete.jsp?page=SomePage to delete the page, the URLs 
could be changed to something like http://bigwiki.org/page/SomePage/GET 
to get a read-only copy, http://bigwiki.org/page/SomePage/EDIT to get an 
editable copy, http://bigwiki.org/page/SomePage/POST to send an updated 
copy, http://bigwiki.org/page/SomePage/DELETE to delete the page, and so 
forth.

Together with this change JSPWiki could generate an ETag (see 
http://en.wikipedia.org/wiki/HTTP_ETag) for each wiki page that is 
changed only when the source wiki page changes.  If a browser needs to 
get a wiki page (in HTML format of course), it will check whether it has 
a cached copy, and if it does, it will include its ETag in the http 
request that it issues.  Most http requests go via a caching proxy 
server somewhere along the line, and these will check if they have a 
cached copy and whether it is still valid.  If so, and if its ETag 
matches that in the browser's request then the caching proxy will return 
a 304, telling the browser that its copy of the page is still current.  
Only if the caching proxy servers don't have a copy of the page, or they 
do and it has expired, will the http request go to the originating web 
server.  It can still issue a 304 return code if the browser's (or 
caching proxy server's) copy of the page is still current, otherwise it 
will send back the new page (converted into HTML) with the page's latest 
ETag.  Most web accesses are read-only, and this surely applies to most 
wikis as well.  RESTful principles would allow the source wiki server to 
offload most read-only accesses to the rich web infrastructure that is 
already in place for just that purpose.

Trevor Turton

Janne Jalkanen wrote:
>
> Nope, you're quite right. This is one of the reasons for the backend 
> change in 3.0.
>
> What I would do is that you should reserve one machine for updates, 
> and have the rest just work as read-only machines. JSPWiki *should* be 
> able to detect any changes, as it would treat them as "someone changed 
> the page manually outside JSPWiki" -events.  You may need to tweak the 
> CachingProvider parameters though.
>
> /Janne
>
> On 7 Apr 2009, at 18:06, Alexey Kakunin wrote:
>
>> Hi!
>>
>> Does anybody has experience of deploying JspWiki into clustered 
>> environment?
>>
>> Actually, we are prepearing EmForge to be installed into cluster of two
>> tomcats used one shared DB.
>> JspWiki played key-role in our project (it is used for storing all 
>> textual
>> information) and many functionality in EmForge are related to JspWiki.
>>
>> Question is - does anybody has experience of deployment of JspWiki into
>> clustered environment.
>>
>> For example - looking into ReferenceManager - there is some info 
>> cached in
>> map, and updated by events.
>> But, if during changing some page, request may be sent to one of 
>> computer in
>> cluster. As result, even will be fired on this node, and reference 
>> manager
>> information will be updated only in this node.
>>
>> So, another node will contain outdated information in ReferenceManager.
>>
>> Same problem (looks like) may happens in CachePageProvider (ok, it is
>> possible to disable caching)
>>
>> Or, I'm wrong - and everything will work well?
>>
>>
>> -- 
>> With Best Regards,
>> Alexey Kakunin, EmDev Limited
>>
>> Professional Software Development:
>> http://www.emdev.ru
>
>