Say goodbye to Sitecore 5.3
No really. Say goodbye. What, just 3 weeks ago, was "designed to drive the largest sites on the planet. ... ... deliver compelling user experiences at lightning speeds using a combination of high availability options, intelligent caching controls, and the power of ASP .NET 2.0" (ref: http://www.sitecore.net/Products/Sitecore%20CMS.aspx) is now yesterday's news.
As I am sure any reader of this blog will know, the new Sitecore CMS flagship, Version 6 (formerly or maybe still known as Crestone) launched on 30th of July 2008, and everyone at Sitecore seems well pleased with it. They have every right to be, don't get me wrong... After what happened "back in the day" when Sitecore 5 was first launched, the transition to Sitecore 6 promises to be a much smoother ride indeed. It looks good, congratulations :-)
This post isn't about Sitecore 6 however. It's about what happens now, to you, to your clients, to your existing Sitecore 5.x solutions.
If it wasn't for the fact that I don't particularly want to spend my entire time blogging on potential and concrete issues in Sitecore 5.x; I could probably still make this a full time profession. Known issues, hotfixes, regression and non-regression tested 5.3 builds...
The question I'm asking is; will we ever get to see a stable 5.3 release now that all the spotlight has moved on to the new emperor's clothes? Surely there must be hundreds if not thousands of 5.x sites out there, and surely one cannot reasonably expect all of them to be willing to invest quite substantially in the upgrade to 6.x just to get a bugfree (or well... tolerable) product?
First line of defense from Sitecore Support seems to see this as perfectly reasonable. Take this recent scenario that played out. You can reproduce this yourself very easily. I tested this on Sitecore 5.3.1 Build 071114 - the only current Sitecore "Recommended Release" (you running 5.3.2?....)
Make yourself a new control, like this:
Simplest control ever. It outputs the current time. Now register this control on a sublayout.
Go to your Layout settings on the sublayout you registered the control on, and make sure caching is enabled (you DO do this by default, I take it..?).
Make sure you've published, and go take a look. Not surprisingly, the Sleep( 10000 ) in there causes quite a delay. Pretend this is your extremely heavy backend integration code executing. After the delay has passed, your page comes up.
Quite as expected. Now click refresh... This is where you start speculating if you did remember to configure caching correctly. I mean, after all, it is quite an involved process with lots of little things to tweak.
The 10 seconds will pass, and voila... Erm.... Well.... there you go, your cached output - again.
So Sitecore realises, AFTER deciding to render your control again (and therefore, running your extremely heavy backend integration code once again), that "aaah... ok let's disregard, and just use what's in cache instead.
Makes a lot of sense doesn't it? ;-)
In case you didn't follow. Sitecore will execute everything, thereby allowing your webserver to consume expensive resources (and even stop and wait for the result), then dump the result and use what it has in cache already.
Mmhmm.
Admittedly, caching and the way Sitecore has to implement it is very tricky stuff indeed. Am not disputing that there's a bug here (... but has this ever worked?). What really got me ticking was the response I got from Sitecore Support on this matter.
"Hi Mark,I have checked this and indeed Sitecore will return cached output but control code will be executed. This was fixed in Sitecore 6.Best regards"
To which, I imagine, there can only be one response; "So?". I have requested information on when a 5.3 fix will be available. Was told this has been put forward to developers, so we'll see what comes of it.
I am stunned however, at how easily the "support decision" was to proclaim that a switch between major versions was the way to go. I don't know about you guys, but I would hate having to go to my customer and go... "You know... I know that 3 weeks ago, Sitecore was the king of kings, intelligent caching and so on. But you see... well... it doesn't really work like intended. Don't worry however, your £75.000 investment is safe and sound. All you need to do, is invest in Sitecore 6 training for your 8 editors (who only NOW are getting to know the system), a simple quick £10.000 upgrade project, possibly a small license increase and THEN we're in business. Really, we are."
Sitecore Support was right, just for the record. The problem described here does not manifest in Sitecore 6.
Is the new mantra really; "Our website is running on it [Sitecore v6] - Why isn't yours?" ?
posted by Mark Cassidy at 15:14
10 Comments:
I totally agree:
Sitecore 5 no longer updated - disaster!
Given the historical cost of upgrading we will have some problems persuading the customer to take this path (very good calculation in your post) - and considering that Sitecore doesn't even provide a viable upgrade path (yet) this is not really an option.
I am also totally stunned by the bug (yes, major bug) you proved by the example (had to test it too - with the same result). Two points makes it a little better though: Firstly I rarely cache sublayouts - we normally limit the use of these to more advanced code (db access or other) which cannot be cached. Secondly the bug does not apply to XSL renderings (which is most often cached).
But still, I am just as concerned as you about the bug and answer from Sitecore Support.
There are a few workarounds, but they all come with negative side effects.
One is to not have a CreateChildControls() method at all. Rename it to something else (instead of overriding) and then call it from your Render() method, followed by a call to base.Render( writer ).
For some reason, Render() doesn't get called when the content is cached. Going this route will mess up a lot of things however, including but not limited to Data Binding for instance.
Not surprisingly, it's "by design". Am still pressing for a better alternative.
----
You can work around this issue by rearranging your code according to the design description below:
Sitecore Version 5.3.x
In Sitecore 5.3.x, caching works on the rendering phase (Render) of the ASP.NET life-cycle. Other phases (Init, Load, PreRender, UnLoad) are executed regardless of whether the control is cached or not.
Sitecore works this way because customers may want to perform tasks each time Sitecore renders the control, even though the control output is cached. Such tasks could include things like collecting statistical data, logging, checking security, and performing interaction between controls.
Because of this behavior, developers should place code that should not be run when Sitecore retrieves a control from the cache in the rendering phase. This is also the reason that developers overwrite the DoRender method rather than the Render method. The Render method will only call DoRender if the control is not cached. For example, a Thread.Sleep call in the DoRender method would not be called when a control is retrieved from the cache.
Sitecore Version 6.x
Sitecore 6 introduces a new feature that caches the CreateChildControls method call for Sublayouts. The ASP.NET life-cycle phases are still run on the Sublayout, but child controls are cached and not created.
Neither Sitecore 5.3.x nor Sitecore 6 support caching on the entire control level, which would mean that Sitecore would not create the control if it already existed in the cache.
Hello Mark,
To bad you're struggling with this. A solution would be to subclass Sitecore.Web.UI.WebControl and to override GetCacheID(). This will make sure you're specific control will be cached in a good way.
About getting a stable release for version 5.3. I guess that's the outcome from the frustration. In the past we've showed that we'll continue to release patches for previous versions(such as v4). As long as there are workitems with enough priority.
We won't change anything in the products, so don't expect large changes which change the product dramatically. But please discuss this particular issue with your local office. They should be able to increase the priority of it.
Hope this helps,
Kind regards,
Alex de Groot
Sitecore Solution Architect
Well...
Thing is; it's "not a bug, it's a feature". At least if one is inclined to just accept the speech that came back from Sitecore support.
If it was indeed truly a feature however, why was this changed in version 6 mmhmm? ;-)
(Rhetorical question really)
But the case in question clearly shows that Sitecore is well aware of the fact that is has cached data on hand for the control. Yet it still chooses to call "CreateChildControls" so that "Sitecore works this way because customers may want to perform tasks each time Sitecore renders the control"... Come on, really! Calling CreateChildControls to execute functionality? Seriously? Does that align with what this method is meant to be doing in standard .NET terminology?
Sematics aside, the major concern in the post is actually 5.3 support in general. As you are well aware Alex, the current 5.3 recommended release is 071114. From mid-November, last year. According to Sitecore, this is the version one should be using unless there is specific reason to do otherwise.
"Please use the current Recommended Release unless you require a fix provided in a specific hot fix release."
Ok fine. And I also understand that Sitecore 6 development has probably eaten up most of Sitecore's developer resources since that November release.
But it's out now, Sitecore 6. Isn't it about time that hotfix 080324 and 080521 were regression tested and a new and current "Recommended Release" be put out for version 5.3?
And most surely, perhaps making it clear to Sitecore Support that just automatically assuming that upgrading to Sitecore 6 is an option, just isn't really applicable in the very real world? ;-)
These are the questions, moreso than the specific bug demonstrated here.
Hello Mark,
Again thanks for your feedback. This is really valuable for us as an organization.
You'll receive a mail later today or tomorrow where I'll write down your concerns to our Support Manager and your local office. I don't think we can really help you by debatting this on your blog. This is not because I want to hide it from the community, but more cause you're pointing on a structural issue.
To react in technical terms: we've upgraded Sitecore 5.1 on .NET 1.1 at a certain point to 5.2 and .NET 2.0. The page lifecycle has changed dramatically.
I think this is a regression bug which goes back to this point. I'm aware that we've released 5.3 meanwhile, but I can also tell you that we're very anxious to change the behaviour of our render engine.
It's a pity that you're running into such an issue. And a shame that it didn't got reported earlier so we could fix it.
Unfortunately it seems that a lot of other people don't need the caching or have found a way around(have you tried my suggestion?).
About Sitecore support: we're aware that we're not living in a world where those decision can be made lightly. But from a perspective of our support team it is the correct answer. Please make them aware in the future that you can't upgrade. We're willing to help you to find a solution for you.
We've managed to help a lot of partners recently with similar issues. Sometimes we've to spent a lot of effort from our side. Sometimes the partner has to do.
In this case I'm sure we can come up with a appropriate solution anyway.
About the recommended release:
We're recommending release based on feedback we receive by our partners. Please supply your experiences with specific builds to your local office. They will contact our release team to come up with a new recommendation.
About product development:
Please be aware that we will not stop to supply to support 5.3. Personally I expect customers to run on 5.3 for the upcoming 3 years.
Our support team is prepared for it. We even have planned every month some time from our R&D team to support it.
But we'll continue to push the new version, as we believe that this is a better system.
With new functionality we're also able to continue backwards support for v6 for a longer time then we were able previously.
Hopefully we can find a solution for your issue. It's on top of my worklist to make sure it will be adressed in our organization.
Kind regards,
Alex de Groot
Sitecore Solution Architect
Appreciated.
I guess http://sdn5.sitecore.net/Scrapbook/Sitecore%20sublayout%20caching.aspx is the result? ;-)
Hello Mark,
Once again this is the result that we take feedback especially from community members like you very serious.
This doesn't mean that you should create a blogpost of all your issues by the way ;).
Hopefully the answers you've received do satisfy you. Please feel free the next time to contact us directly.
http://projects.info-pull.com/moab/ springs to mind ;-)
But in short. No. The post was never about the specific bug, it was about the attitude from Sitecore Support towards Sitecore 5.3 in general.
Seems we'll be getting a lot of "it's not a bug, it's a feature".
I just had to laugh at this post, not because it's bad, but because it's SO true!
I just received an email today from Sitecore support saying that one of my outstanding support issues had changed status.
Naturally I logged in to the support portal only to find out it was a support issue from about 6 months ago (concerning a bug in 5.3.1). The response to this issue? "This issue has been fixed in v6" and the issue was marked as "Solution Provided". HA!
I completely agree that Sitecore should continue to release updates for 5.3, at least to the point where it's as "stable" as v6. It's just silly to think that for any future unresolved bugs or problems we'll encounter with 5.3 that the solution is to upgrade to v6. Like you said Mark, in the real world that's not a viable solution for the clients that have just sunk $$$$$$$ into launching their now defunct application.
Post a Comment
Links to this post:
Create a Link
<< Home