Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
The content you're reading is getting on in years
This post is on the older side and its content may be out of date.
Be sure to visit our blogs homepage for our latest news, updates and information.
Thanks to our great community we have discovered a hard-to-track bug that happens on websites with a greater amount of traffic. Since you may be experiencing this bug as well, we’ve decided to publish the workaround here on the blog as well as some background.
The error manifests itself every so often and the page you see looks like this:
The bug happens mostly on websites with higher amounts of traffic and it happens when the same page is requested concurrently, at the very same moment. The problem is in the fact that even though the two pages are running in separate threads, the cache of the page that was requested first (and I mean first as in “just a bit” before the second one) is valid for the second page. The cache of the second page should not be valid for the first page, because it should be thread dependent, but it is. The particular error happens then as the first page progresses through its lifecycle, the second one enters that very same lifecycle and we get the “RegisterRequiresControlState can only be called before and during PreRender”.
We have already fixed this issue for the upcoming Service Pack 2, but we do understand this is a really big issue to some of you and we wanted to give you a workaround in case you need it right now or if you are not planning on upgrading to Service Pack 2 as soon as it is released.
We’d like to apologize to everyone who experienced the problem. We would also like to thank everyone who reported the issue and provided us with many details which enabled us to pinpoint this bug.
View all posts from The Progress Team on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.