Pascal, you are right about the date changing if copied. The issue I have is that with a large wiki (> 750 pages) you lose much of the LastModified functionality unless the memory available to cache is greater than 1GB and numerous processes time out due to calculation effort and cache thrashing. At the same time all other requests are blocked, making the wiki overall unresponsive.
I do not think that Craig made an error in how he handled the threading in RecursionContext, this is just necessary processing, but other expensive operations mean that there is significant delay in the release of the lock when all details of the wiki cannot be held in cache. Craig, you are probably right about the timeframe needed to implement, it does look like nearly a week. If I do it I will only comment out the existing code for the current LastModified so that it is easily restored as the existing implementation is fully correct. John Davidson On Nov 23, 2007 4:17 PM, Pascal Normandin <[EMAIL PROTECTED]> wrote: > Hello, > > Regarding the following > > > Rather LastModified can always be determined by inspecting topic.wiki > > for the creation date. > > I was just wandering if that could cause some problems since the truth about > the last modified date would no longer be stored in the file name but in the > filesystem metadata of the .wiki file. So if for some reason, the namespace > is copied somewhere on any kind of media for backup purpose and then reused > later on the server the output could be different. Can that be a problem? > > Pascal > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Craig > Andera > Sent: November 23, 2007 10:21 AM > To: 'FlexWiki Users Mailing List' > Subject: Re: [Flexwiki-users] www.flexwiki.com cutover Thursday > > > > I have discovered that each worker process has its own copy of the > > cache and it will be slightly different in each copy, until that > > process expires. > > Yeah, that's a major problem - it's the reason that FlexWiki can't be load > balanced, in version 1.8 or 2.0, against either the filesystem or SqlServer. > Solving it is a very hard problem, although using something like memcached > is probably a solution. Certainly we're not going to fix it for 2.0 or > likely even 2.2. > > The good news is that the way I've designed the caching, the changes are all > in once place - the IWikiApplication. So maybe someday someone will fix it > up. > > > I believe the issue of blocking is with the lock in RecursionContext. > > Disabling security does not eliminate this lock. > > OK, I'll have a look. It's one of the very few places where we needed to > deal with threading, and I may have messed something about it up. > > > One of the biggest calculations is for a Topic.LastModified datetime. > > The current algorithm is extremely inefficient in that it inspects all > > topic*.awiki files, gets all the dates and sorts them into first > > created to last modified order and then iterates through until the > > highest date. > > Boy, this is one of those places where a change to use IQueryable<T> would > really be nice. Of course, that's not going to happen any time soon, > especially given the dependency on .NET 3.5 it would introduce. I have an > alternate design in mind that would fix this problem, but it's another > moderately big refactoring, and I'm not up to that right now. > > > This comes from using a generic routine needed for > > getting all revisions datetimes and then reusing it for LastModified. > > Rather LastModified can always be determined by inspecting topic.wiki > > for the creation date. I suspect this change will bring a significant > > performance improvement for numerous pages using wikitalk and for the > > LastModified.aspx page. > > > > I can start on it Monday and will probably need 2 days to complete, but > > if someone can get started before that it would be great. > > Adding yet another operation to IContentProvider is a fairly big deal, as > you know, from at least two perspectives. First, there's the fact that it > makes the interface less compact - enough modifications like this, and we're > back to the mess the code was in 1.8. > > Second, you have to keep in mind that the changes need to be made to at > least the following types: FileSystemStore, SqlStore, ContentProviderBase, > IContentProvider, TopicCacheProvider, AuthorizationProvider, > CachingProvider, BuiltInTopicsProvider, DependencyRecorder, > ModificationRecorder and NamespaceManager. And of course all of those > changes need tests as well. > > In this case it might be worth it, but two days is probably a bit light for > an estimate unless you mean two full days. > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Flexwiki-users mailing list > Flexwiki-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flexwiki-users > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Flexwiki-users mailing list > Flexwiki-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flexwiki-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
