WampSharp icon indicating copy to clipboard operation
WampSharp copied to clipboard

Logging

Open darkl opened this issue 12 years ago • 19 comments

There should be logs in the framework.

A logging framework (such as log4net) should be considered.

darkl avatar May 04 '13 22:05 darkl

Being developed on logs branch using Castle ILogger interface. An interesting option is to use LibLog.

Please comment here about specific logs you would like to have from the library.

darkl avatar Mar 20 '15 23:03 darkl

Use LibLog :+1:

shanielh avatar Mar 25 '15 13:03 shanielh

In the case of Autobahn's Python, JavaScript and C++ clients I found the debug flag helpful. Something similar may be good for WampSharp, for example, being able to see the JSON that was serialized or deserialized.

fconrady avatar May 14 '15 23:05 fconrady

Yeah, the serialized json is actually written to logs in the develop branch. You are welcome to try it via MyGet feed and add other suggestions.

darkl avatar May 15 '15 00:05 darkl

If you want to expose some Monitor event for logging, that might be handy. Trace calls (System.Diagnostics) would also work, but I generally prefer them less. I would not integrate some 3rd-party logging solution. Leave that to the application-level integration so that they can chose the right logging library for the application -- it's not a framework thing.

BrannonKing avatar Nov 22 '16 17:11 BrannonKing

@darkl I actually ran into a perf issue because I was sending not-small json messages over Wamp and the sync logging was waiting to write out massive strings before continueing. I switched the logger to async, but I was wondering if was possible to either A) only write messages on a parse failure or B) but message writing behind it's own flag completely.

RichiCoder1 avatar Dec 14 '16 11:12 RichiCoder1

Option A is already possible, just set the log level of the logger WampSharp.Newtonsoft.JTokenMessageParser to Error level.

Elad

darkl avatar Dec 14 '16 11:12 darkl

There's no way to it specifically though, since it pulls the logger effectively out of thin error w/ LibLog. So I'd have to set the context of my whole application to something higher than debug.

RichiCoder1 avatar Dec 14 '16 11:12 RichiCoder1

I am not around a computer right now, but for example for log4net you need to create a Logger.config with a ROOT logger set to debug and a logger with the name I mentioned set to ERROR.

Then you need to call XmlConfigurator.Configure. This should work.

Elad

darkl avatar Dec 14 '16 11:12 darkl

See here for the exact syntax.

https://logging.apache.org/log4net/release/manual/configuration.html

darkl avatar Dec 14 '16 12:12 darkl

I utilize Serilog, but the issue is I'd like to keep the log level set to Debug and have Json messages not automatically be written, even at Debug level.

RichiCoder1 avatar Dec 14 '16 13:12 RichiCoder1

So manually change the log level of this specific logger. This is one of the things logging frameworks are for.

darkl avatar Dec 14 '16 14:12 darkl

Apparently Serilog added a source context minium level override a few months back, so my point is indeed moot. Sorry about that.

RichiCoder1 avatar Dec 14 '16 15:12 RichiCoder1

Great!

darkl avatar Dec 14 '16 16:12 darkl

LibLogs perf is catastrophic, at least when used with Serilog. Its spending 90% of time in reflection (resharper profiling tells that), compiling lambdas. LibLog may be an ok case for applications, but with current lack of perf a no-go for libraries/frameworks.

llehn avatar Aug 04 '17 20:08 llehn

LibLog has absolutely horrifying performance. It should not be used in a library/framework at all. My simple loop publishing a message to a web client eats loads of CPU managing only 1000 messages/sek. All with loglevel disabled to minimum. All time is spent in LibLog which calls reflection and Expression.Compile() on every published message.

llehn avatar Aug 04 '17 20:08 llehn

LibLog is designed for libraries. The only places in the code where .Compile() is called (at least for the Serilog provider) is in static context (i.e. static constructor or the SerilogLogProvider constructor which happens once). This should be ok for most cases.

darkl avatar Aug 04 '17 21:08 darkl

I also just submitted a pull request which fixes all Expression.Compile per instance/per message calls to static calls. This should resolve all such issues if they exist.

darkl avatar Aug 04 '17 21:08 darkl

Thank you! I just tried your changes with WampSharp - throughput went from 1200 messages/sek to 13000 messages/sek. So the issue did exist. I'll do a PR to this repo using the code from your PR.

llehn avatar Aug 04 '17 22:08 llehn