You can read the full discussion here:
Microsoft.WindowsAzure.Plugins.Caching.ClientDiagnosticLevel value="1" does not disable INFORMATION traces, and changing the value to "0" (critical) has no effect.
We have decided not to fix this issue at this point since we think it doesn't impact very many customers.
All CAS logs are enabled for info level tracing and this is cas log. This should not cause so much of noise, but for any reconfigurations of server and routing table refreshes.
Please let us know if you disagree.
I have run into the same issue when adding Azure Caching to my project it's made the WADLogsTable unusable for me.. I'd love to see a fix for this.
I agree with dipson. WADLogsTable is completely useless. How can I make sense of my application's diagnostics when I get hundreds of these useless messages each minute. This issue MUST be re-opened. The customer MUST have the ability to manage their diagnostics in Windows Azure.
What are my options?
Just to add, this hell started when I started using Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider as my application's session provider. This, of course, is a recommended approach for enabling session across instances in Azure. How could you possibly think this doesn't impact many customers? Perhaps many of your customers are simply silent on the matter (after-all, WADLogsTable is cumbersome to use anyway - I made a point to try to follow best practices and make the most of it though my efforts have now been rendered useless)?
This ought to be fixed. That is too much noise to sift through in WADLogsTable. This is another reason to switch to a cloud logging service.
@piyushjo, Please re-open this issue. i can't use my WADLogsTable since i started using the azure in-role cache. i get TONS of those useless records
This is a serious problem. Diagnostics trace logging is the recommended solution for Azure logging. You've now completely swamped it with log messages that are irrelevant and meaningless to everyone in the world except for you. I can't see what's going on in my application because you're so intent on giving me detailed information on the internals of the cache client. It's ridiculous. At the very least, these messages should be dropped to a lower priority.
Tell you what, next time you're reading a log file imagine that every interesting message was surrounded by 100 lines of unreadable, undocumented garbage from a library you referenced. That's what my logs look like now. Imagine how infuriating it would be to diagnose a problem under those circumstances.
Note that as the old Azure Shared Caching and project migrate to the new Azure Caching Service this will impact more and more users. So look forward to more complaints about this.
Also, since you mentioned that it should only log for reconfigurations and be "not much" logging, I attached a screenshot of my logs.
Thank you for your feedback. I have reopened this issue so we can consider fixing this in a future release.
Thank you. Please keep us updated about this. Personally, I stopped using the storage diagnostics since this started..
By the way, the category of these records is "Error". For the very least it should be "information".
Yes, please fix this. I am seeing the unnecessary logging on my Silverlight app. Not only is it annoying, but I suppose I am getting charged for the transactions by Azure.
Agree the chatty tracing is an issue. The product team is going to take a good look at the cache service over the coming months and I'm going to make sure to follow up on this. Thanks!
Is there some way to filter this in code? For example, can I tell the diagnostics to only include messages with a level of 'Warning' or higher?
FYI, I have tried to configure Diagnostics to only transfer Warnings to storage, but these stupid 'information' logs are getting transferred anyway.
Please help me so I don't have to wait months to get this figured out.
@reswat , as i said in my last comment, i believe that those spammy records are labeled as "Error" (level 4) and not "Information".
but maybe there is another way to filter .. so if anyone find out how, please let us know
Thanks for the comment.
I use Azure Diagnostics Manager by Cerebrata to view the messages. Using that tool, those messages definitely show up with an Event Level value of 'Information'.
But like you say, it would seem like we should find a way to filter this regardless.
OK. I believe I found a way to limit the garbage messages by filtering out Information messages. This is not ideal - I had to go into my code and change all my trace message from Information to Warning. So, I lost the ability to distinguish between true warnings and just information messages. But at least I don't have all of that garbage now
I tried to post the solution here, but when I posted a sample from my Web.config, it didn't translate to a readable form here. How do I post XML code here?
just create a snippet in:
Thanks for the pointer on posting XML, but it turns out that I didn't need to modify my web.Config. I just modified the diagnostics configuration (to transfer only Warnings to storage) using the Server Explorer in Visual Studio, as described here:
After making that change, the garbage Information messages stopped showing up. Again, that's not ideal because I had to change all my Information messages to Warnings, but I believe it's better than before.
I think it's pretty clear that there's no trace level granularity so the lib traces everything as soon as tracing is enabled.
I managed to stop it by completely disabling the traces from my code:
@ThomasWeiss where abouts in your solution did you add this code Tom?
@piyushjo is there a timeline on this issue being resolved? I can see the issue was created a year ago yet our logs are still full of <CASClient> and <Complaint> information level logs. It seems to occur on each and every request to our in-role cache; with the removal of the old caching service we don't have much choice but to use the new service.
Has anyone successfully disabled the Information level logs with a workaround?
@lukemerrett I put that in the static constructor of a class that handles the Azure cache.
@ThomasWeiss thank you for the response Tom; we tried that out and it worked like a charm.
This issue is affecting us too - please fix it. I'd like to be able to control what goes into our log.
Adding my vote - please fix
An average of 8 entries per minute is a mess, more than one year with the issue opened.
With the availability of Redis on Azure and Microsoft's clear "recommendation" to use it instead of previous proprietary cache solutions, it's now obvious that this issue will never get resolved.
I've moved to Redis with excellent results, I would encourage you all to consider it.
@SiddharthChatrolaMs please address or close this issue
We do not have any plan to fix it now as we have redis out there
Please correct me if I'm wrong but I don't think Redis cache could be used as In-Role cache.
Lol what a joke. If simple things like this aren't fixed, why is this package not marked as deprecated? i.e. do not use as we're not developing it further? Why would you migrate it to storage 4.3 from 1.7 but not fix this?
Also if this much discussion is needed to fix what seems to be a one line bug then wow!
As far as session state, Redis is a great solution, but there is no proper drop-in SessionStateProvider as of yet, one that does not require [Serializable] on your types. RedisSessionStateProvider from Microsoft specifically is not a drop in replacement and no source code is released.
Also if there is spare memory in your roles why wouldn't it be used for caching? So there is a use for this, but not 'enough' so we're not going to develop it.. ok.
It's a joke. Fix this or discontinue this lib.
session state provider is open source now: https://github.com/Azure/aspnet-redis-providers