No evidence of logging

I've added Raygun.Diagnostics (v <IP_ADDRESS>) package reference in my windows service project using nuget. I've modified my app.config so that it looks like the example below.
<system.diagnostics>
    <trace autoflush="true" indentsize="4">
        <listeners>
            <remove name="Default" />
            <add name="myListener" type="System.Diagnostics.TextWriterTraceListener" traceOutputOptions="DateTime,LogicalOperationStack,ThreadId" initializeData="trace.log" />
            <add name="RaygunTraceListener" type="Raygun.Diagnostics.RaygunTraceListener, Raygun.Diagnostics" />
        </listeners>
    </trace>
</system.diagnostics>

Throughout my code I have many calls to Trace.WriteError() which when they are encountered do not seem to log anything to raygun.io. Do I have to do anymore for configuration above the standard .NET integration (instantiation of RaygunClient)?

You must also have the raygun configuration in your app.config as well. I would also recommend calling Trace.TraceError() instead of Trace.WriteError().
<configuration>
  <section name="RaygunSettings" type="Mindscape.Raygun4Net.RaygunSettings, Mindscape.Raygun4Net" />
</configSections>
<RaygunSettings apikey="myAppKey" />

Thanks, I'm using Trace.TraceError(). I've corrected my original post. Will try this and report back.

Adding the API key specified in the config file seemed to do the trick. This has me wondering if there is a way to do the same through code.

yes, you can specify the key through code if you would like.


Add introspection of commands in odin data applications

Commands are now supported via https://github.com/odin-detector/odin-data/pull/359, so fastcs-odin should introspect these and create Attributes.
I think we want new type of summary attribute that would allow us to create an AttrRW() that when set pokes other attributes to send the commands, and reads from an AttrR for its current state. In this case when set to 1 it would poke "start_writing", when set to 0 it would poke "stop_writing" and update its readback from "writing". This could possibly be a separate issue if it proves complicated and this one can just be for creating the PVs for individual commands.

[ ] Depends on https://github.com/odin-detector/odin-data/issues/363

You have mentioned a new type of summary attribute.  Just to clarify exactly what you are thinking.  This would be something like a CommandSet, which would take:

A container of ConfigFanSender attributes, enumerated so that poking a specific value sends the "command" to that particular ConfigFanSender (or you think you need a new CommandFanSender?)
A single SummaryAttribute which is used to obtain the current return value for this new CommandSet ?

This would be generic enough so that you could for example have ["Start", "Stop"] and this reads back the writing state (0,1).  Or you could have ["cmd1", "cmd2", "cmd3"...] and this would read back some state attribute relaying the current state if that was ever required.
Have I understood correctly what you are thinking?

Once we have commands being introspected, there should be a new CommandFanSender to create a top-level start and a top-level stop. There is already a top-level writing for the readback.
Then we need a CommandSummaryUpdater (with a better name) that combines these three things, pokes start when set to 1, pokes stop when set to 0, and uses writing for the readback. This can be attached to a AttrRW(Bool()), which should be turned into two buttons and an led by pvi.
Possibly this will require some FastCS or pvi changes to achieve.


HADOOP-17520. Downgrade missing DDB table to unguarded client

2689

 Quality gate: Passed
2 Issues

 2 Code issues

Details