My use case

[Scott Corscadden]

So… I like what I see here, and am considering replacing what I've built for some apps we have, to compare&contrast. However before I start digging in, I wanted to see whether you (and the group) thought my use case was worthwhile. Here's what I have in my existing application:

• Log4J-style loggers, via defines, across each class I use a "logger" for. 
• A plist-style configuration file in the application which defines a global "level", plus any number of key/value pairs for class/level (allows per classname detail).
• Log to a file while on-device, with a set range the file size can be, currently simplified as a "low-water" max, and a "high-water" max of 2x the low-water one. When the high-water max is crossed, it's truncated back to the low-water threshold.
• On application minimize, we write a separate "Clean Exit" file. On resume/startup, if we don't detect said file, we auto-send the current log file to us (devs).

This seems to be working well for us, but has some limitations (I'm using lower-level functions, mmap (PROT_READ, MAP_SHARED), fseek, etc for speed) but I'm not certain that iOS will inform me if/when my usage crosses a watchdog (or other) boundary that it deems inappropriate (and thus shoots my app). We don't use the app store (enterprise MDM instead) so we don't see any OOM style crashes, and I am still getting the occasional "no clean exit" send of data from our apps to us, hence my interest in trying a drop-in replacement of Lumberjack for some targeted users of ours, to see if things improve. 

In order for this to work for us, I'd need a few things, which I'm not sure Lumberjack would support. I'm happy to code up subclasses and configure as necessary, but don't want to stretch the architecture if it won't fit. I'd need:

• Synchronized, immediate write to a single log. I may move to asynchronous/queued writes, but we rely on our loggers getting the "last log written" right before a crash sometimes
• All logs still logged in release builds, obviously
• Some form of log-truncation, if possible. Otherwise I'll have to use the log rotation and merge in files (which may not be hard, IIUC).
• #define'd switching between what we have and Lumberjack usage (this seems dead easy, really). 

So that's it, thanks for listening, and comments very welcome. Very nice code there, from what I've seen so far!

./scc

[Robbie Hanson]

It sounds do-able.

For the plist style configuration, there's an experimental branch that supports something very similar. I know of several devs that use it, I just haven't had time to clean it up and merge it into master.

Synchronous logging is all configurable. So if you don't want anything asynchronous, it's as easy as flipping a switch. You can also manually "flush" at any time. That is, invoke [DDLog flushLogs], which won't return until all previous log statements have completed.

Log truncation is also do-able. But may involve a little bit of subclassing. Probably not too difficult.

 Let me know if you have any questions.

-Robbie Hanson

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "CocoaLumberjack" group.
To view this discussion on the web visit https://groups.google.com/d/msg/cocoalumberjack/-/bIiu8O6zxB0J.
To post to this group, send email to cocoalu...@googlegroups.com.
To unsubscribe from this group, send email to cocoalumberja...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cocoalumberjack?hl=en.