Stop logging maps in ContextManager

[milleruntime]

No description provided.

[EdColeman]

Are these frequent? Does not having a context convey information to the user?

Would something like

log.debug("Managed Contexts: {}", context == null ? "none" : contexts);

be too busy?

[milleruntime]

Are these frequent? Does not having a context convey information to the user?

They are being logged every minute, so not too crazy but every time 3 messages get printed. I don't think empty context helps users much. This is a deprecated class and was for the old context class loading. But I have never used the feature so maybe someone with more expertise in the class loading can weigh in.

[milleruntime]

log.debug("Managed Contexts: {}", context == null ? "none" : contexts);

This isn't much different from what we have now. I could combined the two messages so it prints them on one line. I think that would be an improvement but if a user never uses the context class loading, then this is still noise to them.

[EdColeman]

I do not know how to classify / balance noise vs. useful information in this case. I can see the viewpoint that if it is useful or important to see the context when you have it configured, the absence could also be informative? - Say you expected it to be set but was not? Or all my others have it set, but why not this one?

It's really hard to go through a log file and find messages that are "missing" - especially if your not sure that you should be looking for them in the first place.

One message seems reasonable as an alternative - but I also don't recall this being and issue - but I am also unsure that if there was a suspected problem, what it would look like and what information would be useful in tracking it down.

[ctubbsii]

Can we just make it so it logs if there are changes?

[milleruntime]

These log statements are getting printed from AccumuloVFSClassLoader.removeUnusedContexts(contextsInUse) which is called in a thread in startCleanupThread() from the DefaultContextClassLoaderFactory. It seems the whole point of the method is to just to remove unused objects so I don't think we need to be printing every time. From a user standpoint, I think they would only care if something is being removed from the unused map, which is printed in the next loop.

[ctubbsii]

It seems the whole point of the method is to just to remove unused objects so I don't think we need to be printing every time.

Do we log elsewhere when the context is initialized, then?

From a user standpoint, I think they would only care if something is being removed from the unused map, which is printed in the next loop.

If the removals are already being logged, and the initialization is already logged, then I agree it doesn't make sense to continually log the current set here.

[milleruntime]

Do we log elsewhere when the context is initialized, then?

It is difficult to tell exactly where things get initialized but I found these log statements.

accumulo/start/src/main/java/org/apache/accumulo/start/classloader/vfs/ContextManager.java

Lines 53 to 55 in 42c84e8

	log.debug(
	"ClassLoader not created for context {}, creating new one. uris: {}, preDelegation: {}",
	cconfig.name, cconfig.uris, cconfig.preDelegation);

accumulo/start/src/main/java/org/apache/accumulo/start/classloader/vfs/ContextManager.java

Line 197 in 42c84e8

log.debug("Returning classloader {} for context {}", loader.getClass().getName(), contextName);