Umbraco version: umbraco v 4.0.0 (Assembly version: 1.0.3327.20280)
Asp.Net: .Net framework 2.0
Windows server 2008 with IIs7
Sometimes when viewing a page with a contained macro, the macro part of that page is completely removed, not rendered, no error no nothing only a incomplete page. Loading the same page again, it's rendered correctly. This occurs very rarely.
When investigating more deeply I found out that this is somehow connected to the recycling of the application pool in which umbraco is running in. Setting the application pool to recycle itself every 1 minute I could reproduce the behavior more often than with the default recycling time but still not consistently after every recycling.
I was never able to reproduce the error when adding the umbDebugShowTrace=true, the page always renders correctly when having it set to true.
Has anyone got a clue about what can cause this or have anyone seen this before?
Note. It just not a particular page with a macro the got this behavior, every page on the site that have a macro on it acts like this when the problem occurs.
I can't replicate your issue - so I suggest you ask this question at our.umbraco.org
There is will get a bit more visibility by the Umbraco core team who may be aware of the issue.
If you have proper steps to reproduce the bug then submit it to the umbraco codeplex site so that it can get fixed.
T
Related
I've been helping a client rebuild a website that is hosted on a IIS 6 (I think) after he fired its IT Director.
One of the tasks was to change all the passwords for DB access, which went just fine.
Given this, we had to recompile the web application/site to reflect these changes (new user/password) and we tried rebuilding the web site (which went fine) and then placing the files on the same folder as the previous ones were, basically replacing what was on the server.
But now, the site won't work at all giving just a bad request and I can't seem to be able to fix this.
I've never used IIS before and the configurations done are the very basic ones (almost nothing really) so I can't seem to understand why this doesn't work.
Could anyone give a hand?
Thanks,
BR
Well, turns out this problem was split in two parts that were causing the problem.
Number 1 was that the Web.config file wasn't properly setup to a production environment and thus causing inaccessibility problems.
Number 2 was that for some reason IIS was set to use ASP.NET v2 and the website was built using .NET 4. Although this shouldn't be a problem it was causing some other problems.
IF someone ever gets caught in the same problem, it's worth checking out these two items, at least, and do a IIS Reset.
We recently migrated a large ASP. website from framework 1.1 to framework 3.5 and in the process also migrated from a website to a web application.
On the surface everything seemed to work fine, but now we are discovering that none of the "pages" are doing what they used to.
The site is made up of one default.aspx page that loads all the "pages" as user controls. (I am guessing this was to achieve the same effect as having a master page before master pages were invented.)
I think we missed a trick (or twelve) during the migration. What are the big stumbling blocks that other people have experienced
Update
We managed to find the problem that was making our pages stop working, but can not figure out why: When we cleaned up the code of the main page, we added whitespace (a newline) between the open and closing tags of the control that all the other "page" user controls get loaded into. Once we removed the newline everything started working again. Can anyone explain this?
I have experienced problems during manual copying etc. that has lost the connection between the GUI controls and the event-methods in the code behind. There are differences between the different versions of ASP.NET on how the event handling is coupled, and there are even more than one way of doing it (automatic based on names or explicit in code), and this is easy to mess up when changing from one "standard" to another, which is what you do converting to a differen version of .NET. It is also an additional source of confusion for Visual Studio when you also converted from Web Site to Web Application.
I am guessing that the trick was just to do some editing in Visual Studio, and VS might have automagically re-attached event handlers etc.
One things you should know is that if your new server is 64 bit. There is a chance that the controls on the page will be loaded concurrently with the page. In a sense there will be a lot of timing issues. If you are not using 64 bit server however this is not relevant.
I have got one weird issue. I am working on an asp .net mvc application. I have a refresh button that build some data and view models in the controller code, and returns the partial view back. Well this refresh does work good the very first time. But when i try to click my refresh button again, a javascript alert comes saying
"out of memory at line 56"
I checked my task manager to see on whats happening. I have a 3GB memory and when this error alert shows up the used memory is 1.41 GB. Its normal usage as it looks like. But I don't know why it shows the javascript error alert.
This problem happens in my local workstation where I am doing development of this application.
Any thoughts or comments to trouble shoot or solve this issue is appreciated. I ma using IE7.
Any infinite loops in there? Javascript doesn't like those.
Another possibility - is there any Flash on the page? Apparently there have been issues related to that in the past where updating your version of Flash fixes the problem.
I'm having some problem finding the source of the problem, but here it goes, maybe you know the magic answer.
I'm running this asp.net site with an AJAX updatePanel on my local machine, and everything works just fine, since it's where I developed it. Now, a few days ago, I uploaded the files to my web-host and assigned every single DataBase, and there is no error messages, even though it's still set to debug mode. There is a problem though, whenever I click an element which triggers my asp.net AJAX updatePanel to update, the whole site is updated(which it should not, only the Panel), and my jQuery's (document).ready is called every time as well.
Thank you for any help, I have no idea why this does not work online, nor' do I know why it does work on my local machine.
I have choosen not to upload the code, since I have no idea where the problem might lie, please feel free to ask for the code and I shall reply :)
Have you checked that your web host either:
a) Is running .net 3.5
b) Has the Ajax extensions for .net 2.0 installed
...and that you are testing locally with the same?
If you don't know what the operation aborted error is, here's a Microsoft KB Article about it, http://support.microsoft.com/default.aspx/kb/927917 . There's also tonnes of posts about it but the simple answer for it's occurrence is this; the error only occurs if you try to manipulate a DOM element via JavaScript before the element you are trying to manipulate is loaded.
I know how Internet Explorer's (IE) infamous Operation Aborted occurs and know how to fix it. The problem I have is a very weird scenario. Testing locally and on a development machine with IE7, I never ever get the operation aborted error (both sites running as http).
However on our client's testing site it occurs all the time. Unfortunately my testing environment is not the same as the client's testing environment, so that adds some variables to the mix, but the main difference I see is that the client's testing site is using SSL.
Has anyone ever had the Operation Aborted error only for an SSL site?
The other thought that popped in my head was that it was a latency issue. Locally the site loads up almost instantaneously whereas on my client's testing site, the page loads slower. So with that in mind, I got Fiddler running and simulated the performance to run at old school modem speeds, still no operation aborted error locally or on our own testing server.
FYI: The site is an ASP.NET 2.0 Site using ASP.NET AJAX Extensions 1.0. The page with the issue also has the AJAX Control Toolkit's Cascading Drop Down on it.
And yes as far as I can tell all JavaScript that manipulates the DOM is at the end of the markup, not the beginning.
Any help or comments is greatly appreciated.
Well after scouring the Internet I found the issue. It has to do with a bug in the the ASP.NET AJAX client-side framework.
I'll paraphrase what I found:
The issue is a race condition that occurs due to an Internet Explorer/ASP.Net AJAX bug. The probability of encountering this issue increases when the application has a significant number of ASP.Net AJAX enabled server controls on the web page. The issue is explained here, http://seejoelprogram.wordpress.com/2008/10/03/fixing-sysapplicationinitialize-again . I have added this fix to the project I'm working on.
This fix is still required if using ASP.NET 3.5 SP1.
I guess the reason why you don't have SSL on your test box is due to the cost of the certificate. Did you know you can get Free short term certificates? I've often used them to sort out issues like this.
For example RapidSSL do a free 30 day certificate.