I have an ASP.NET MVC5 website and I have installed Glimpse.MVC5 using nuget. The website is running the latest version of the Sitecore CMS (7.2 rev. 140314). I haven't changed the Glimpse configuration at all apart from adding logging.
When I go to the homepage of the website (after enabling Glimpse) I can't see the HUD. The following is the last line in the Glimpse log:
2014-04-24 15:19:01.6043 | DEBUG | Apparently GlimpseRuntime has not
yet initialized this request. This might happen in case you're doing
something specific like mentioned in this issue:
https://github.com/Glimpse/Glimpse/issues/703 . Either way, Glimpse
will be disabled to prevent any further non-deterministic behavior
during this request.
I've had a look at the link but I can't see that it applies to my situation. There are no NullReferenceException's in the log.
I have tested Glimpse.MVC5 with a vanilla ASP.NET MVC5 website on my machine and that worked fine so I'm tempted to assume that it's something to do with Sitecore.
Any ideas what could be wrong or ideas on how to identify the issue?
The solution mentioned in this post on the Glimpse issue tracker solved the problem.
Sitecore does it's own HttpModule stuff which seems to
cause issues.
In order to fix this, you need to move the Glimpse HttpModule
definition before the Sitecore modules in the Web.config.
The reason why you are still not seeing the HUD is explained by that log message as well.
Somehow during the execution of the request, a new HttpContext is created or used which means you'll loose the request initialization that Glimpse did at BeginRequest. As part of that initialization, items are being stored in the HttpContext.Items collection for which Glimpse will look during request monitoring.
The message you see in the log is an example of when Glimpse wants to know what the current RuntimePolicy is, so that it knows whether or not it should continue to monitor that request. The current RuntimePolicy is set by Glimpse during the BeginRequest phase of that request and the log now indicates it cannot find it, after which Glimpse decides to be concervative and stop monitoring that request instead of ending in a NullReferenceException
Now the cases where we've seen that (check the linked issues inside the issue you mentioned) is when another HttpContext is being created and used to process that request after that Glimpse did is initialization.
So the only advice I can give here, is to check whether the creation of another HttpContext is actually the case for you? You might find some ideas in those linked issues.
In case you find something specific that is not related to the issue mentioned above, then I would suggest you create a new issue on our issue tracker as it is a more appropriate place to discuss potential bugs or missing features
Related
I'm using liferay portal community edition 6.1-
I'm trying to export a portal in order to move the content to another intance of liferay. however, when trying to export the portal content the export fails with message 'Your request failed to complete."
When looking at log files, there is no sign of anything going wrong.
Could someone please explain to me what can possibly be wrong, and from where should I get the information for what is failing on server?
Marko
I've been digging into similar issues with the LAR importing/exporting system myself. There isn't much logging in that code unfortunately. I ended up enabling remote debugging in the server's JVM and stepping through the problematic tasks using the Eclipse debugger.
One of the main issues I've had with Liferay is that it swallows detailed exceptions, doesn't log them, and waters them down into very generic error messages by the time they're displayed to you in the UI. Using the debugger really helps because you can often see the original exception without having to dig too deeply into the code.
How's your free disk space looking on the server? I believe Liferay saves the LAR to a temp file as it works on it (at least, it does as part of the publishing process). On our test site, with only ten pages and almost no content, that temp file is still 3.5M. If your site is really big you might just be running out of space.
I just attempted to update the site map provider from 3.3.6.0 to 4.0.14. I followed the instruction on the wiki however my SiteMapPath now renders empty. I made no changes to the mvc.sitemap file other than updating the schema to 4.0. When I debug into the SiteMapPathHelperModel I find that the model has no nodes defined. I am using the internal DI container (I would like to get this working before switching over to the application container).
When I check the sitemap.xml file it is well populated which makes me think that the mvc.sitemap is being read.
I'm out of ideas on this one and would be happy to provide any additional information which may be useful. I'm not even sure where I can hook into debug this problem. Literally the only thing I changed between a working 3.3.6.0 and a not working 4.0.14 was what was prescribed on the wiki.
Ok, since your /sitemap.xml endpoint appears to be working, you are correct the sitemap is being populated and loaded correctly.
There are a couple of things I know of that can cause this to happen:
If you are using Dynamic Node Providers, they must be added to a node that is not otherwise part of the sitemap. See my question here - I am trying to figure out why this is the case as well.
Your routes don't match your nodes - please read Routing Basics and/or post your routes and Mvc.sitemap XML.
If you check the above and everything appears to be correct, please make a small demo project showing a sample of your configuration and open an issue on GitHub, as it is highly likely your specific configuration has something to do with the problem.
BTW - You can debug by cloning the current repo on your system or downloading the solution as a zip, enabling NuGet package restore on your solution (right click the solution > Enable NuGet Package restore), add the MvcSiteMapProvider project to your solution, and then in your project remove the reference to MvcSiteMapProvider and add the reference to the newly added MvcSiteMapProvider project from your MVC project. Then you can add breakpoints and step through the code. I suggest making a backup of your solution (or ensure you can roll back another way) before doing this, and reverting back to your current state when done.
I have documented the whole procedure here: http://www.shiningtreasures.com/post/2013/08/21/debugging-an-mvcsitemapprovider-configuration
I have somehow got into a strange situation with my CRM system.
A plugin I have developed is not getting updated correctly when the solution is imported. When I choose to maintain the customisations the plugin updates dont get applied, but when I choose to overwrite customisations the steps get doubled up and so the plugin gets fired twice.
Has this happened to anyone else? How do I stop this from happening?
Thanks
I've had a similar situation where I had plugins registered twice after importing.
I believe the way I solved this was:
Use the plugin registration tool to remove the plugin from the server you are deploying to.
Reimport the solution.
I can't see you doing any major damage here, but I would suggest backing up the server first because I'm not 100% on this one.
Are you assigning a strong name to the assembly? I've seen this kind of thing happen in CRM 4.0. If you don't assign a strong name with a key, CRM doesn't seem to see that it is the same assembly.
If you deploy the plugins using the plugin registration tool, solution deployment will duplicate all of the steps as it does not recognise the deployed plugin steps as their ID is changed.
If plugin assembly is deployed without the steps, you've forgotten to add the steps into the "Sdk Message Processing Steps" section of the solution.
#JamesWood approach will always work but is very heavy handed for a production environment, an IIS Reset and restart of the MSCRM services (in services.msc) usually clears any cached plugin assembly, while a redeployment should only be needed/used in dire situations.
I'm trying to write an HttpModule to run on our SharePoint farm - essentially it will check whether the user is authenticated and if they are it will validate some info against another database and potentially redirect the user to sign a variety of usage agreements.
Whenever I enable the module in the web.config I'm finding that SharePoint has issues rendering the page - it's almost like the CSS is not getting loaded as the page is devoid of any styling.
As a test I've even tried an empty module - i.e. an empty init block so it's not even hooking up any code to any events and the same issue arises. At this point it's an empty class that just implements IHttpModule so it's not even my dodgy coding causing the issue!
The module is in a class library that I've dropped in to the bin folder of the application it needs to run against. In the web.config of the app I've simply added an entry as below:
<modules runAllManagedModulesForAllRequests="true">
... (default stuff ommitted)
<add name="SharePointAUP" type="SPModules.SharePointAUP" />
</modules>
I must be missing something really obvious here as I've done exactly the same as every sample I've found and yet I'm getting this strange behaviour. Is there something extra I need to do to get SharePoint to play nice with a custom module?
UPDATE:
In case it helps - this is SP 2010 beta running on Windows 2008 R2.
UPDATE:
The set-up I'm running against is a farm - 2 front end servers with NLB & 2 app servers with services split across them.
After listening to a nagging feeling this morning I've tested my handler on another installation we have which is a standalone set-up... and everything worked perfectly. The issue only exists when deploying to a farm.
make sure to include a precondition attribute
I came back to this after reinstalling the farm with the RTM - everything worked fine. I've written it off as beta issue (along with many others that I had with SharePoint if you've seen my other questions!).
Everything works fine for most accounts 100% of the time but here and there some users who are able to access a subsite fine one day are greeted with a standard 404 the next. This can last for an hour or two days, it's really inconsistent.
I check the iis logs and it says the status is also a 404 for these requests, nothing else looks unusual. Sharepoint logs have nothing for the timestamps either.
Correct me if I am wrong but if it was a permission issue an access denied message would be shown.
It is not the individual computer because when a user is having this problem and I can log in with their account and I also get the 404 error although I am on the exact site with another account in another browser at exactly the same time, and it works perfect.
Any suggestions would be greatly appreciated, I've done a fair amount of searching but can not find a similar situation or help anywhere.
Since the information is very strict at the moment, I will throw a few questions that might lead you towards the problem.
Are we on a loading balance setup? The intermittent 404 might be cause by one of the servers Web FrontEnds not correctly serving requests.
Are we running out of disk space in the SQL Server machine? This might cause it
Are the blogcache or site caches enabled? Some routines may break them
Do we have Anti-Virus on the server? (it HAS to be asked :p)
We get very high packet loss between the servers? (The error would be different though)
Something that might occur very often is when you have, say, custom code a DLL on the GAC or the bin folder, and since you could be on loading balance the second server does not have this DLL in its own GAC or BIN folder. Sharepoint usually raises 404s when assemblies are not found too, not only requests.
This seems like a longshot, but... could those SharePoint sites be throwing a 404 HttpException? It seems like you'd see that in the SharePoint logs, too, so it's even more unlikely.
At any rate, is your SharePoint logging level set to an appropriately verbose level to debug weird stuff like this?
Are people checking in & publishing master page changes when new CSS files and/or other includes (script files, etc.) are not yet published at all? I've seen this cause a 404 a few times when users forget to check before they publish.
I have had to write custom code within a SharePoint context and I had those 404 errors as well. The solution, in my case, was to ensure that the block of code executing had these 2 conditions met:
1) Run with elevated privileges, regardless of the fact that it is a 404 this was part of the solution.
2) web.AllowUnsafeUpdates = true; This line of code needed to be added even though it was wrapped within an elevated privileges block.
Once these were added the issue did not occur. This was happening on both load and non-load balanced environments.
This reminds me of a strange asp.net bug that I had a few months back.
It was caused by a patch that had been applied (to the framework if I remember correctly)
try downloading this Windows update list tool and have a look at what has changed since the problem started.
I concede that if there was a problem with a patch then its more likely that it would be a consistent error, but it's worth a look.
It was a permission issue, I had figured this out awhile back but basically a few accounts were not setup properly and could not load a fresh copy of the page, when someone else would hit it they would be able to view the cached page fine. Error was never thrown as a permission issue or access denied anywhere but this is what fixed the problem.