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
