ppkarwasz commented on issue #3252: URL: https://github.com/apache/logging-log4j2/issues/3252#issuecomment-2511920370
@jpcmonster, This is a real deadlock caused by a recursive call between the Log4j [`PropertiesUtil.getStringProperty()`](https://logging.apache.org/log4j/2.x/javadoc/log4j-api/org/apache/logging/log4j/util/PropertiesUtil.html) and the Spring [`JndiPropertySource.getProperty()`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jndi/JndiPropertySource.html). The steps to reproduce are: 1. `JndiPropertySource.getProperty()` initializes Artemis. 2. Artemis locks `BeanUtilsBean`. 3. Log4j calls `new Logger()` after locking `InternalLoggerRegistry`. 4. Log4j looks for the `log4j2.flowMessageFactory` property in all available property sources. 5. We are back at step 1. This cycle should explain both the deadlock and the stack overflow. PR #3263 will eliminate the stack overflow and the dead lock. In the meantime you can: 1. Either forcibly disabling `JndiPropertySource` by setting `spring.jndi.ignore` to `true` (see [JndiLocatorDelegate#IGNORE_JNDI_PROPERTY_NAME](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jndi/JndiLocatorDelegate.html#IGNORE_JNDI_PROPERTY_NAME)). 2. Or, if you are not running in a Servlet environment, remove the `java.naming.*` system properties, since Spring does not use them to start Artemis. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
