Got a slightly odd one here.
We have an MVC site that is experiencing some instability. Once a week for the last couple of weeks the site has gone down. We have found that all we need to do to bring the site back up again is 'touch' the web config file (i.e. open it and save it, with no changes). This brings the site back to life immediately and keeps it alive for another week or so.
The site has custom error pages set up so we can't actually see the error that is being thrown, and there is nothing appearing in the IIS logs.
It looks like some kind of memory leak problem, however .NET garbage collector should manage this, right?
Any ideas?
Thanks,
Pat
You should have some kind of logging so that you can see what error you get. I usually use elmah. That will give you the full error message and stack trace. It's pretty hard to say what the problem is without knowing the error. But it can be a memory leak of some kind. Do you use a lot of unmanaged code? The garbage collector can't handle everything.
Touching the web.config forces recompilation and refreshes the app pool. My guess is something is knocking out your app pool, whatever it is will be in the event logs, i suggest you check there.
Related
We recently put live EPiServer output caching, this works fine locally and on our staging sites. For some reason since going live yesterday pages don't seem to stay in the cache for long, if at all. I can't see any obvious reason for this aside from genuine traffic?
To implement caching I added [ContentOutputCache] to the get methods of certain controllers. Then updated the Application Settings with the following:
uiUrl="~/EPiServer/CMS/" httpCacheExpiration="12:0:0" httpCacheVaryByCustom="path" httpCacheVaryByParams="id,epslanguage"
Has anyone seen anything like this before. I can't figure out why the cache keeps being dropped. Interestingly chrome tells me that the content is coming from the cache but the page load time is upwards of 20 seconds at times ... other times it's instant (when the caching is working).
I am not logged in to the CMS and no one is publishing anything.
Please let me know if you need any more info as always any help greatly appreciated on this.
Thanks,
Dan
I've inherited a big #$$ Delphi Application that by itself are so full of problems, that I'm not sure how I will be able to track down a problem that I'm currently getting.
The application crashes and terminates abnormally, and I'm unable to establish a pattern. I've added madExcept, and that helped me a lot getting some other problems, but when the application dies, not even madExcept is able to stop it so that I can get an exception report. I've downloaded Eurekalog as well to see if this can help me, but no luck.
Does anybody have a solution on what I can try. Any tool that will be able to help me out in tracking down the problem. SmartInspect does have some kind of solution, but I will have to change a lot of code for it to work, and unfortunately the main unit of this application sit with over 53k lines of code. (Just nasty).
Any help on what I can use to track this error will be appreciated. I need to but this "tracker" on a user machine because this application is running live at almost 2000 users.
If anybody also know why a random RICHEDIT20.DLL access violation will pop up now and again, it will be very usefull, because why it happens just baffles me completely.
Thanks
Jaques
Last time I had to do such a task (when Eureka and mad didn't suffice), I included CodeSite (Raize) logging, so you can log initially at key points in your application. In several cycles you'll need to add more to narrow down the problem. Advantage of CodeSite is that it enables you to log to another machine, so if your application crashes the system, the logging will be secured.
While developing, these errors end up in the console, and a lot of them don't impact my application. But once I get in production, any minor error will bring up the "this application crashed!" message and the only option is to reload. Why does SproutCore crash my app out at the drop of a hat?
Web developers are used to being able to let minor errors go unnoticed. This is appropriate: since short-lived websites often have minimal local state to maintain, many minor errors won't impact the user experience, so it may not be worth the development time required to fix them.
Application developers, on the other hand, are used to having to carefully handle errors. In desktop .NET or Cocoa, for example, the operating system will proactively crash an application that throws an unhandled error. This is because applications generally assume that they are long-lived, and have to manage an internally-consistent state. An error is a sign that this internal state has likely become unmanaged & unstable, and in order to prevent unexpected (or worse) behavior, the application must be terminated.
SproutCore is a collection of full-featured application development frameworks for use in the browser, and a SproutCore web app differs from short-lived, largely stateless web pages in a number of ways. Most importantly to this discussion, they are very application-y in terms of their long lifetime and robust internal state. As with desktop applications, unhandled errors are an indication that your SproutCore app's internal state has likely become unmanaged and unpredictable. Since SproutCore has no way to determine whether a particular error is benign or problematic, it shuts the whole thing down – just like other application systems.
SproutCore doesn't crash the app as aggressively in development mode in order to give you a chance to examine the error's cause and fallout to determine how to handle it. So to build robust, stable web applications, just keep an eye on your console, and either prevent or handle any errors that pop up.
Dave's answer is perfect, but I'll just add one bit of technical detail:
When in a production build, Sproutcore attaches a handler to the browser's javascript onerror event. This way, the user gets visual feedback that there was an issue, rather than have the app just suddenly stop responding to any input.
However, in some browsers the onerror handler can prevent a developer from seeing the full stack trace of the original issue. Thus in development mode (using sc-server or similar), the handler is not used and the exception is not addressed at all by Sproutcore. Then the browser will do something like log it to the console where you can see the original cause. I also recommend setting the developer console to 'break on uncaught exception', so that it lets you inspect the context where the error occurred.
I have several websites that are currently experiencing the following problem. Over time, rendering of a specific partial view (asp.net mvc 1) will degrade, and take around ten times longer than it does normally. I currently have a workaround, but it's far from ideal.
Take this node off our load balancer
Stop IIS
Delete all temporary asp.net files
Start IIS
Hit the site to get caches populated and views compiled
Put the node back on the load balancer's rotation.
I know that it's not the restarting of IIS fixing it, it seems that the temp asp.net files have to be deleted for this to work properly. After those steps are completed, performance on the site is much, much better for around three to six hours. After that, it goes back to being terrible. The partial view that's having issues pretty much just renders out some html with cached data. We have not been able to reproduce this issue in our dev environment at all, so we're pretty stumped. We're going to be upgrading our live environment shortly, so I'd just like to know what's causing this problem. If it's configuration related at all, I want to make sure it's fixed with our new setup. Anyone ever seen this before?
There could be many things at play here, an initial check list
confirm app is not deployed in debug mode
what logging do you use and is it being done excessively?
what is the bottleneck on the server when this happens? memory? then you might have to check for a leak
do you regularly recycle your app pools?
Can you give some more details on what this partial view actually does?
The solution for this problem was to clean up the temporary asp.net files. We integrated this step into our deploy process, and the site overall has been running faster.
I'm having an issue with an umbraco site of mine: For some reason some of the nodes are timing out when I try to click on them in the back-end of the site.
The front-end works fine and there aren't any slowdown issues there, however I'm unable to edit these same nodes in the back-end as the system seems to just hang. This is making it incredibly difficult to debug as I have no idea what properties are actually causing the problems here. What's strange is I can create a node of the same document type and enter in some dummy values and that works fine, yet I can't seem to edit the existing nodes.
I've tried republishing the entire site, republishing the individual nodes, deleting the umbraco.config file and nothing has worked up to this point.
What's also interesting is that if I close down the browser the system seems to stop hanging and I can log in and try again.
Has anyone encountered this before or know where to begin?
Thanks
I have encountered something similar. The longer you work with Umbraco the slower it becomes and if you check the memory usage in Chrome's task manager, you can see that certain actions upon nodes bump the memory usage up a little further. The answer is just to close down the tab and open a new one.
I have reported this and Umbraco cannot replicate this. However, I do think that this is possibly due to maybe a package installed into Umbraco, maybe uComponents. It's very difficult to pin point.
Update:
If you can access some nodes but not others, then this is actually slightly easier to debug. I would check what similarities the nodes that timeout have.
Are they all of the same document type?
Do they all use the same data type?
I would guess that the nodes in question are using a data type that is performing an operation when the node is loading, and that operation is timing out. For example, do you have any data types that load data from the database, like enums? Do you have any datatypes that load data from a web service?
Do you have any usercontrol data types wrapped in the UserControlWrapper data type? These would be somewhere to check.
Finally, check:
The databases [umbracoLog] table. Any Umbraco-specific errors will be listed there.
Check the computer's event viewer. This will show any unhandled errors.
My money's on a database timeout.