Potential race condition when initializing Logback
See original GitHub issueUsing SpringBoot version 1.3.2.RELEASE
Occasionally my tests fail with the error below. It is sporadic, but it appears that one LoggingSystem might be cleaning up when another is initialized.:
Caused by: java.lang.IllegalStateException: Logback configuration error detected:
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - There is no conversion class registered for composite conversion word [clr]
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - Failed to create converter for [%clr] keyword
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - There is no conversion class registered for composite conversion word [clr]
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - Failed to create converter for [%clr] keyword
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - There is no conversion class registered for composite conversion word [clr]
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - Failed to create converter for [%clr] keyword
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - There is no conversion class registered for composite conversion word [clr]
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - Failed to create converter for [%clr] keyword
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - There is no conversion class registered for composite conversion word [clr]
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - Failed to create converter for [%clr] keyword
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - There is no conversion class registered for composite conversion word [clr]
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - Failed to create converter for [%clr] keyword
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - There is no conversion class registered for composite conversion word [clr]
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - Failed to create converter for [%clr] keyword
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - There is no conversion class registered for conversion word [wEx]
ERROR in ch.qos.logback.core.pattern.parser.Compiler@729ed61b - [wEx] is not a valid conversion word
ERROR in ch.qos.logback.core.pattern.parser.Compiler@71516065 - There is no conversion class registered for conversion word [wEx]
ERROR in ch.qos.logback.core.pattern.parser.Compiler@71516065 - [wEx] is not a valid conversion word
at org.springframework.boot.logging.logback.LogbackLoggingSystem.loadConfiguration(LogbackLoggingSystem.java:153)
at org.springframework.boot.logging.AbstractLoggingSystem.initializeWithConventions(AbstractLoggingSystem.java:71)
at org.springframework.boot.logging.AbstractLoggingSystem.initialize(AbstractLoggingSystem.java:49)
at org.springframework.boot.logging.logback.LogbackLoggingSystem.initialize(LogbackLoggingSystem.java:106)
at org.springframework.boot.logging.LoggingApplicationListener.initializeSystem(LoggingApplicationListener.java:262)
at org.springframework.boot.logging.LoggingApplicationListener.initialize(LoggingApplicationListener.java:233)
at org.springframework.boot.logging.LoggingApplicationListener.onApplicationEnvironmentPreparedEvent(LoggingApplicationListener.java:200)
at org.springframework.boot.logging.LoggingApplicationListener.onApplicationEvent(LoggingApplicationListener.java:176)
at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:163)
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:136)
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:119)
at org.springframework.boot.context.event.EventPublishingRunListener.publishEvent(EventPublishingRunListener.java:111)
at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:65)
at org.springframework.boot.SpringApplicationRunListeners.environmentPrepared(SpringApplicationRunListeners.java:54)
at org.springframework.boot.SpringApplication.createAndRefreshContext(SpringApplication.java:330)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:307)
at org.springframework.boot.builder.SpringApplicationBuilder.run(SpringApplicationBuilder.java:134)
at org.springframework.cloud.bootstrap.BootstrapApplicationListener.bootstrapServiceContext(BootstrapApplicationListener.java:129)
at org.springframework.cloud.bootstrap.BootstrapApplicationListener.onApplicationEvent(BootstrapApplicationListener.java:78)
at org.springframework.cloud.bootstrap.BootstrapApplicationListener.onApplicationEvent(BootstrapApplicationListener.java:58)
at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:163)
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:136)
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:119)
at org.springframework.boot.context.event.EventPublishingRunListener.publishEvent(EventPublishingRunListener.java:111)
at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:65)
at org.springframework.boot.SpringApplicationRunListeners.environmentPrepared(SpringApplicationRunListeners.java:54)
at org.springframework.boot.SpringApplication.createAndRefreshContext(SpringApplication.java:330)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:307)
at org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:98)
at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:98)
at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:116)
... 51 more
I’ve tried to create a sample application that consistently triggers the behavior, but the best I’ve been able to do is initialize the logging system a bunch in separate threads and observer that similar occur (though not identical)
for(int i =0; i < 100; i++){
new Thread(() -> {
LoggingSystem system = LoggingSystem.get(LoggingSystem.class.getClassLoader());
system.initialize(new LoggingInitializationContext(environment), (String)null, (LogFile)null);
}).start();
}
Issue Analytics
- State:
- Created 7 years ago
- Comments:35 (17 by maintainers)
Top Results From Across the Web
c# - Multithreading - Race condition to initialize shared data
In my web service I've cache object (contains static data) based on the session id. Once request is received it checks whether cache...
Read more >PatternLayoutBase concurrent access race condition
So, when we have multi-threaded appender, we end up with the issue writing to the same StringBuilder concurrently.
Read more >Java Concurrency - Race Conditions - Read-Modify-Write
Greetings! When two or more threads access shared data at the same time race condition occurred. These operation should be atomic to thread-safe...
Read more >Finding potential thread safety issues and race conditions in ...
If you are using Logback or Log4j the getClass().getSimpleName() is unnecessary, you can set in the log4j.xml or logback.xml to log the ...
Read more >[Solved]-Race Condition On Save Event-Java - appsloveworld
Coding example for the question Race Condition On Save Event-Java. ... Race condition in java agent between initializing ThreadStart event callback and ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@bin01 Upgrade logback to 1.1.7 did not help and we have yet not upgraded spring boot. Workaround which we did is working for us. It is bit different from one mentioned above. As we are driving our logging using logback.xml and not by logging configuration in application.properties, therefore we skipped revitalization of
LogbackLoggingSystem. Here is what we did, we crated below class and added it to classpaththen passed
-Dorg.springframework.boot.logging.LoggingSystem=com.ca.tdm.utils.AppLoggingSystemas jvm argument.and we are done.
you may also try switching to different logging system. like
-Dorg.springframework.boot.logging.LoggingSystem=org.springframework.boot.logging.log4j.Log4JLoggingSystemWe are facing this problem quite frequently, We have spring boot (1.3.0) application with hibernate hibernate and we are using external logback.xml. We upgraded logback to 1.1.7 but no success. It looks like Hibernate Validator is initialized in different thread using BackgroundPreinitializer. When spring boot is re-configuring logging system, Hibernate Validator is having handle to old logger instance, which is causing the problem Stack traces:
stacktrace.txt
Defect Logs:
**ROOT CAUSE:
Thread Stack: when logging system is initialize as default:**