accumulo icon indicating copy to clipboard operation
accumulo copied to clipboard

Added Logger which emits a log based on a condition

Open dlmarion opened this issue 1 year ago • 6 comments

Fixes #4409

dlmarion avatar Apr 23 '24 17:04 dlmarion

I added a more general comment on #4409, While this may be useful in some cases, I'm not sure it solves the original issue.

Mainly it seems that this would be hard to use when there is unique information in the message that should be passed along. If we need to treat "issue tablet x" and "issue tablet y" as different messages and not as repeat occurrences of the same message, this seems to want to treat them the same.

EdColeman avatar Apr 23 '24 20:04 EdColeman

In f679cd3 I modified the Logger to be based on a generic condition and added a time based implementation that uses a configuration property for the time interval. Like @EdColeman mentioned, not sure how useful this is, but I can envision wanting to log things in a server when some condition is true.

dlmarion avatar Apr 23 '24 20:04 dlmarion

Would there be any benefit of allowing the property to be dynamic and stored in ZooKeeper? That would also require a watcher to react to updates - and that is likely to make using this class much harder, basically a server context would likely be required to get the instance / zoo reader / zoo watcher.

It would really complicate the code, but would allow things to be adjusted without restarting services.

The other draw-back would be because this is a general property, setting it will change all instances and it may be really hard to know what they are.

One alternative could be to use log4j and isLevelEnabled to toggle between messages and or message frequency. Something like the following using a count, or could be modified to use a time.

   if(LOG.isTraceEnabled()){
      LOG.trace("always log");
    } else if(LOG.isDebugEnabled() && (count++ % 10) == 0){
      LOG.debug("log every 10");
    } else if(LOG.isInfoEnabled() && (count++ % 100) == 0) {
      LOG.info("log every 100");
    }

Then, using named loggers and standard configuration, the level for that class could be dynamically adjusted at runtime on a named logger basis?

EdColeman avatar Apr 23 '24 20:04 EdColeman

The other draw-back would be because this is a general property, setting it will change all instances and it may be really hard to know what they are.

yeah, this is a problem. Currently there is no way to modify the properties of a single server at runtime for debug purposes. I think the standard way to do this is using JMX.

With JShell, manipulating JMX beans becomes easier I think.

dlmarion avatar Apr 24 '24 12:04 dlmarion

I had an issue with the implementation regarding AbstractLogger implementing Serializable. I reworked the implementation and removed the Property. I also added @keith-turner's message deduplication implementation to this.

dlmarion avatar Apr 24 '24 15:04 dlmarion

These changes were merged into #4558

dlmarion avatar May 14 '24 16:05 dlmarion

These changes were merged as part of #4558

dlmarion avatar May 28 '24 17:05 dlmarion