Flushing Appender

[dracozombie19]

Hello,

I was wondering if there was a built in method for flushing the log messages for a particular appender. I have a situation where I want to remove an appender, but I want to force it to send out its messages before I do that. I found that I can call sendLogItems directly to do this, but I feel like it's inappropriate to be calling a function like this that seems like it is more of an internal function. If I'm using the buffering I can just force a miscellaneous log of a message at the sendWithBufferLevel to push the messages out. However, if I'm doing the batching instead I don't see any obvious way. I know I can set the batchTimeout option (which I am doing currently) to have it periodically send, but I was hoping there would be a way to force it early.

[mperdeck]

No, there is no "official" method to flush an appender. It never occurred to me that somebody would want to remove an appender.

Why do you want to remove an appender? I'm trying to understand your use case.

[dracozombie19]

There are a couple reasons. First, I want to use different appender configurations based on the log level set in the app. In the app I have a dialog I can use to change the log level for my session so I can get more detailed information outside of scenarios raising an error. I tried just using the setOptions function to update the existing appender, but that was causing the appender to go crazy and log everything in batches of 1 regardless of what options I was setting when I changed it. the only way I've found to get it working properly so far is to remove the previous appender, then create a new one with the new options and add it.

The second reason is probably less important as I think there are other ways around it. Basically, I have an AjaxAppender that I only want to run once the user has logged in. So when they hit the login page the first time or when they log out, I want to disable the appender. I didn't try it, but I could probably set the appender level to be Off to prevent any log messages, but with the issue mentioned above it was just easiest to implement it the same way.

[mperdeck]

Instead of changing appenders, it may be easier to change your root logger.

http://jsnlog.com/Documentation/JSNLogJs/Logger/SetOptions section "Logger names and option inheritance"

For example, a logger "a.b" inherits its level from the logger "a", unless you override the level on "a.b". And "a" inherits from the root logger (the logger with no name).

So maybe you can simply update the level on the root logger, and not change the appenders.

To get a reference to the root logger: var rootlogger = JL();

See http://jsnlog.com/Documentation/JSNLogJs/JL/JL

[dracozombie19]

As I mentioned, it is not just the log level that I am changing. I'm switching between using batching and using buffering based on the level, so I need to adjust more options than just that one. Simply performing a setOptions() call on the Appender is not working, so I am completely removing the Appender and creating a new one.

To add to that, I'm currently using both the ConsoleAppender and AjaxAppender in one Logger. I have ConsoleAppender writing everything to the console, but AjaxAppender is only reporting back to the server based on whatever the session log level is. If I set the level on the Logger, the ConsoleAppender will also be impacted by that.

Also, from what I've been seeing, the Logger level impacts the buffering behavior on the AjaxAppender. It seems the Logger only reports messages to its Appenders if those messages are above its level. Therefore if I leave storeInBufferLevel as the default ALL, but change the Logger level to, say, Error, then only Error messages will ever make it to the Appender to be put in the buffer. That completely defeats the purpose of using the buffer.

[mperdeck]

It turns out that the appenders (ConsoleAppender and AjaxAppender) actually do expose a method to flush the batch buffer: public sendBatch(): void

This method is called when the batch timer expires. I made it public a while ago to enable flushing of the batch buffer when the page gets unloaded, but never documented it on the web site.

I'll update the web site to document this method.

This does not flush messages that were stored because of the storeInBufferLevel setting. The idea with these messages is that you only want to send them if a higher severity event happens - which is not going to happen anymore when the page unloads. Obviously you can force these messages to be flushed by logging a high severity event.