Thanks Blair - we tested our fix as detailed last week, and as far as we can tell, it appears to remove the behaviour we were seeing. i.e. we don't lose containers any more when approving while someone is concurrently requesting the page for viewing. We'd been able to replicate the problem consistently using jMeter and adding the login check to container.cfc has removed that problem.
We've deployed to production today, and appears to be stable so far as well, so if all remains well, we'll consider that a fix until we can move to 6.x release. Thanks for the help and pointers everyone! Colin. On Feb 25, 11:07 am, Blair McKenzie <[email protected]> wrote: > I'm no expert on this bit of FarCry, but it sounds pretty safe. I think Matt > made his change further up the processing chain to reduce processing as much > as possible, but if you aren't a container guru like him your approach is > probably safer. > > Keep in mind that you don't have to make the change in core - you > *should*be able to extend container into your project and override the > createData > function there. > > Keep us posted. I'm interested in knowing if this is a solid solution we can > recommend to others in the same situation. > > Blair > > On Thu, Feb 25, 2010 at 9:12 PM, Colin Jones <[email protected]> wrote: > > OK - we've come up with this (based on your post Blair): > > > In packages/rules/container.cfc we've added a CFIF to check that you > > have generic webtop permissions before allowing the createData method > > to be called... seems to work... can you see any problems with this > > approach? > > > <cffunction name="createData" access="public" returntype="any" > > output="false" hint="Creates an instance of a container object."> > > <cfargument name="stProperties" type="struct" > > required="true" > > hint="Structure of properties for the new container instance."> > > <cfargument name="parentobjectid" type="string" > > required="No" > > default="" hint="The objectid of the object that instantiated the > > container. Should only be set if the container is unique to that > > instance. Will enable clean-up of unused containers when the parent- > > object is deleted."> > > <cfargument name="dsn" type="string" required="false" > > default="#application.dsn#"> > > <cfset var stNewObject = structNew()> > > > <cfif application.security.checkPermission("Admin")> > > > <cfscript> > > stNewObject = > > super.createData(arguments.stProperties); > > if (len(arguments.parentObjectid)) > > > createDataRefContainer(objectid=arguments.parentobjectid,containerid=stNewObject.objectid); > > </cfscript> > > > </cfif> > > > <cfreturn stNewObject> > > </cffunction> > > > On Feb 25, 9:07 am, Colin Jones <[email protected]> wrote: > > > Ah - so you're saying that simply viewing the page (as a public user) > > > forces farcry to create empty containers if there are none against the > > > page in the DB, and as we haven't got to that stage in the draft -> > > > approved process it ends up getting the empty containers instead? > > > > Our problem is that we aren't immediately going to be able to move to > > > 6.0, however we need something to patch this in the meantime. Any > > > idea where this code is triggered in 5.2.3!? Could we disable it > > > somehow there? :) > > > > On Feb 24, 10:30 pm, Blair McKenzie <[email protected]> wrote: > > > > > Hi Colin > > > > > This is an issue we've had as well. It happens because FarCry creates > > empty > > > > containers for pages that don't have any in the DB. While FarCry is > > busy > > > > migrating the draft page to live ... for a very brief moment the page > > is > > > > empty. We fixed the problem in FC6 by removing the automatic creation > > > > process. Now containers are ONLY created if a user views a page in rule > > > > editing mode. > > > > > Blair > > > > > On Thu, Feb 25, 2010 at 2:46 AM, Colin Jones <[email protected]> > > wrote: > > > > > Thanks Chris - I think we have also narrowed it down to core as > > > > > well... > > > > > > We've tried two independent websites using FarCry - totally different > > > > > projects on different servers, the other one running 5.2.7 of core, > > > > > and have been able to successfully replicate this behaviour simply by > > > > > loading requests on the page while approving in the webtop. > > Sometimes > > > > > you have to go through the 'draft/approve' loop a few times before it > > > > > happens, but it doesn't take long before you lose the rule containers > > > > > on the page. > > > > > > This is obviously a very serious core bug, as changing a page > > > > > (particularly the homepage) on a site with heavy traffic means that > > > > > you can lose every rule on it - clearly something that is likely to > > > > > affect the homepage more often than others by the nature of traffic > > > > > patterns. Editing rules themselves has no effect, and you can > > happily > > > > > change those without this behaviour manifesting. Seems to be just > > > > > moving a draft version of the page itself to approved causes it - > > > > > which seems to link it back to that bug again... :( > > > > > > Problem is this is severely knocking the confidence of our editing > > > > > team in the system... they are already printing out copies of things > > > > > because they feel that it isn't reliable! > > > > > > (PS: Thanks for the info on caching, but as performance hasn't been a > > > > > problem, we're not pursuing that at the moment - this however we have > > > > > to find some resolution to!) > > > > > > On Feb 24, 10:32 am, Chris Kent <[email protected]> wrote: > > > > > > Colin, > > > > > > > Yes, adding something like > > > > > > * @@cachStatus: 1 > > > > > > * @@cacheTimeout: 5 > > > > > > is simple caching, refreshing after 5 minutes > > > > > > > But for dynamic content you can also set the cache to check for new > > > > > > type content and then flush the cache if there is something new to > > > > > > display. Check out @@cacheTypeWatch, Geoff had a nice quick demo of > > it > > > > > > working on the AUS Winter Olympic site at last weeks cfmeetup > > Farcry 6 > > > > > > presentation - > > >http://www.meetup.com/coldfusionmeetup/pages/Recordings_of_the_ColdFu... > > > > > > & > >http://carehart.org/cfmeetuprecordings/20100218_CF%20Meetup_%20FarCry. > > > > > .. > > > > > > for the downloadable flv. > > > > > > > As for fixing the conflict between setting content to approved and > > > > > > grabbing content for display - this will require a fix within > > farcry > > > > > > core code. > > > > > > > Chris. > > > > > > > On Feb 24, 10:15 am, Colin Jones <[email protected]> wrote: > > > > > > > > We're not using webskin caching - just objectbroker caching of > > the > > > > > > > database requests. > > > > > > > > Webskin caching caused us other problems with dynamic content, so > > we > > > > > > > never enabled it. (I'm assuming you mean View Caching described > > > > > herehttp:// > > docs.farcrycms.org/display/FCDEV50/UNIT+08+-+Object+Broker,+Vi. > > > > > .. > > > > > > > ) > > > > > > > > We have narrowed it down to that final "submit" for approval on > > the > > > > > > > screen that asks you for the approval comment. If we run without > > load > > > > > > > up to that point, then load the page requests for that page just > > prior > > > > > > > to pressing the final submit, it loses all the rules on the page. > > > > > > > > On Feb 24, 9:31 am, Chris Kent <[email protected]> wrote: > > > > > > > > > Colin, > > > > > > > > > Sounds like some form of locking should be put in place - i.e. > > do not > > > > > > > > allow nj:display to get content item whilst set status to > > approved > > > > > > > > (statustoapproved) process is in in progress for that same > > item. > > > > > > > > > Are you using webskin chaching, if not it might be worth > > looking into > > > > > > > > if you are not, The cached version of the webskin may (have not > > > > > > > > tested) still be available for display whilst the content item > > is > > > > > > > > being approved. Not sure, without looking, what the sequence of > > > > > events > > > > > > > > are when approving content - i.e. does the full DB update > > complete > > > > > > > > before the webskin cache is cleared? > > > > > > > > > Chris. > > > > > > > > > On Feb 24, 8:37 am, Colin Jones <[email protected]> wrote: > > > > > > > > > > Hi we've just encountered a major problem when trying to edit > > our > > > > > > > > > (busy) homepage. We have various rule containers on there, > > but if > > > > > we > > > > > > > > > create a draft version - even just to change some metadata on > > the > > > > > > > > > page, then send it to approved we're frequently losing > > several > > > > > rules > > > > > > > > > from the page randomly. > > > > > > > > > > This appears to be directly related to this bughttp:// > > > > > bugs.farcrycms.org/browse/FC-523 > > > > > > > > > which does not appear to have a fix. We are currently > > running > > > > > 5.2.3 > > > > > > > > > of farcry. > > > > > > > > > > We can replicate it every time on dev and test by running > > jakarta > > > > > > > > > jmeter against the page to simulate continual requests. If > > the > > > > > page > > > > > > > > > is edited while the page is being requested continually any > > or all > > > > > the > > > > > > > > > rules on the page end up disappearing. Obviously this is a > > major > > > > > > > > > problem for us and the editors, as we could be randomly > > losing > > > > > content > > > > > > > > > all over the site, and people may not even notice it's gone > > > > > > > > > immediately. > > > > > > > > > > If anyone has any ideas on how to fix this they'd be greatly > > > > > > > > > appreciated! > > > > > > > > > > Cheers, > > > > > > > > > Colin. > > > > > > -- > > > > > You received this message cos you are subscribed to "farcry-dev" > > Google > > > > > group. > > > > > To post, email: [email protected] > > > > > To unsubscribe, email: > > > > > [email protected]<farcry-dev%[email protected]> > > <farcry-dev%[email protected]<farcry-dev%[email protected]> > > > > > > For more options:http://groups.google.com/group/farcry-dev > > > > > -------------------------------- > > > > > Follow us on Twitter:http://twitter.com/farcry > > > -- > > You received this message cos you are subscribed to "farcry-dev" Google > > group. > > To post, email: [email protected] > > To unsubscribe, email: > > [email protected]<farcry-dev%[email protected]> > > For more options:http://groups.google.com/group/farcry-dev > > -------------------------------- > > Follow us on Twitter: > > ... > > read more » -- You received this message cos you are subscribed to "farcry-dev" Google group. To post, email: [email protected] To unsubscribe, email: [email protected] For more options: http://groups.google.com/group/farcry-dev -------------------------------- Follow us on Twitter: http://twitter.com/farcry
