Recently we have encountered an issue where there is a high CPU usage in our system and it is pointing to our code using AbstractXMLObjectUnmarshaller. Upon further investigation, this has been caused by an existing bug in JDK 11 where the current workaround is to just set the Logger instances to static.
I have checked that there is already an open issue related to this , and based on the comment the fix would be to change the Logger instances to static. I'm not sure what is the scope of this change, so i would just like to propose that it covers all the `Logger` instances in the codebase.
GIven that this is a library, doing that would essentially render it impossible to use different logging contexts in multiple applications that share a container and are using the library. That’s why libraries tend not to do static loggers.
That said, Shibboleth is the only supported use case for this library and Shibboleth doesn’t need to co-exist with other applications, so…sure?
But if this is just a bug in Java 11, if it’s fixed, the new LTS release is a month out, so it seems unnecessary to do it just for that reason when V5 (the soonest we would do this) is a long way off.
Hello,
Recently we have encountered an issue where there is a high CPU usage in our system and it is pointing to our code using
AbstractXMLObjectUnmarshaller. Upon further investigation, this has been caused by an existing bug in JDK 11 where the current workaround is to just set theLoggerinstances tostatic.I have checked that there is already an open issue related to this , and based on the comment the fix would be to change the
Loggerinstances tostatic. I'm not sure what is the scope of this change, so i would just like to propose that it covers all the `Logger` instances in the codebase.Thank you