locked
Controlling cache log verbosity. RRS feed

  • Question

  • Hello Everyone,

    We are using Windows Azure Caching v1.8.1.0 in an MVC 4 application. Caching is co-located with the web role. Everything works great, but out trace logs are full of messages such as:

    WARNING: <SimpleSendReceiveModule> DeadServerCallback Called, Server URI: [net.tcp://10.115.160.145:20004], Underlying exception - ; TraceSource 'w3wp.exe' event

    and

    INFORMATION: <CASClient> Updated partition table to (1-601) generation: 634880264105879210:1000000000000000000000000 with transfer (1-601) generation: 634880264105879210:1000000000000000000000000; TraceSource 'w3wp.exe' event

    and

    INFORMATION: <Complaint> Add hard complaint :0 ; TraceSource 'w3wp.exe' event

    Search inside referenced DLLs shows that all these messages are coming from the caching package.

    Caching diagnostic level is set to the default 1 (error), and cache tracing sink level to "Error":

    <Setting name="Microsoft.WindowsAzure.Plugins.Caching.DiagnosticLevel" value="1" />
          <Setting name="Microsoft.WindowsAzure.Plugins.Caching.ClientDiagnosticLevel" value="1" />
    <tracing sinkType="DiagnosticSink" traceLevel="Error" />

    Changing logging levels in the above settings does not affect the behavior. These messages look purely informational, so it would be very nice to be able to control the verbosity.

    Googling did not turn up anything useful. Any help will be greatly appreciated.

    Friday, November 30, 2012 1:45 AM

All replies

  • I am seeing the same problem and have same settings, logs are getting flooded. Any way to control the log spam without losing diagnostic information? Please clarify
    Friday, November 30, 2012 10:44 PM
  • In my case I upgraded from cache preview SDK 1.7 to production caching SDK 1.8. The upgrade process did not cleanup web.config settings. After removing the setting in app.config and web.config, I did not see the log spam.

    The following link had manual changes required after upgrade is done.http://msdn.microsoft.com/en-us/library/windowsazure/jj835079.aspx

    They say to remove <tracing sinkType="DiagnosticSink" traceLevel="Error" />. Worth giving a try. It worked for me.

    Thanks

    Anil Lingamallu

    Saturday, December 1, 2012 12:35 AM
  • Thanks for pointing me in the new direction.

    Wouldn't removing <tracing sinkType="DiagnosticSink" traceLevel="Error" /> cause all messages to be discarded, not just the high verbosity ones? Sounds potentially dangerous to me. I would like to see real errors, should any occur, in the logs.

    Sunday, December 2, 2012 8:26 AM
  • sorry, here is the correct link for the upgrade scenario http://msdn.microsoft.com/en-us/library/windowsazure/jj651665.aspx

    From what I understood, for production caching, the config setting <Setting name="Microsoft.WindowsAzure.Plugins.Caching.ClientDiagnosticLevel" value="1" /> does same thing as <tracing sinkType="DiagnosticSink" traceLevel="Error" />.

    I have seen some intermittent caching failures even after removing <tracing sinkType="DiagnosticSink" traceLevel="Error" />.

    Monday, December 3, 2012 8:51 PM
  • Sorry for the delay in replying.

    I did remove the <tracing sinkType="DiagnosticSink" traceLevel="Error" /> entry and it had absolutely no effect on the verbosity of the cache client. Same amount of junk clogging the logs. Any other ideas?


    Sincerely, -Anatoli

    Tuesday, December 11, 2012 2:52 AM