[jira] [Commented] (LOG4J2-2921) Enable parallel test execution for compatible tests
[
https://issues.apache.org/jira/browse/LOG4J2-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533194#comment-17533194
]
Piotr Karwasz commented on LOG4J2-2921:
---
Due to the [Github-hoster runners
characteristics|https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources],
the execution time can be cut by *at most* half on the CI.
> Enable parallel test execution for compatible tests
> ---
>
> Key: LOG4J2-2921
> URL: https://issues.apache.org/jira/browse/LOG4J2-2921
> Project: Log4j 2
> Issue Type: Improvement
> Components: Build, Tests
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>Priority: Major
>
> One area to improve the execution time of our builds is to [enable parallel
> test
> execution|https://junit.org/junit5/docs/current/user-guide/#writing-tests-parallel-execution]
> for all tests that can support that. Parallel tests are run in multiple
> threads on the same JVM rather than in forked JVMs (our current
> configuration). Thus, any tests that don't rely on JVM-global state (e.g.,
> does not use environment variables, system properties, changing the default
> locale, shares an output file, etc.) should be able to support parallel test
> execution. Considering the amount of overhead introduced by JVM forks for
> every test, I'd hypothesize that this change could shave off at least 5-10
> minutes from the total build time.
> JUnit 5 provides the ResourceLock annotation which can be used to create
> generic locks (similar to ReadWriteLock in Java) for various resources. It
> defines some default ones like for setting the locale, system properties,
> system out, system error, and the timezone. Any other shared resources
> outside those contexts could likely use custom string values for the
> annotation.
> h3. Custom Resources
> * {{log4j2.MarkerManager}} (since MarkerManager uses a static map, tests
> that create non-trivial markers may interfere with each other)
> * {{log4j2.StatusLogger}} (covers both changing the logger level as well as
> relying on StatusData entries in the logger)
> * {{log4j2.TestLogger}} (this test class maintains static state)
> * {{log4j2.LoggerContextFactory}} (for tests that change
> LogManager.setFactory() or depend on the currently configured
> LoggerContextFactory via LogManager methods)
> * {{log4j2.Level}} (defining custom levels)
> * {{java.lang.SecurityManager}} (for tests setting a SecurityManager)
> h3. JUnit and Surefire Options
> * {{junit.jupiter.execution.parallel.enabled = true}}
> * {{junit.jupiter.execution.parallel.mode.default = concurrent}}
> * {{true}}
> * {{}} is currently 1, though this might be useful to change to 1C
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-3497) ConstraintValidator's are not employed by PluginManager
[
https://issues.apache.org/jira/browse/LOG4J2-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532950#comment-17532950
]
Matt Sicker commented on LOG4J2-3497:
-
PluginRegistry keeps a cache of scanned plugins. PluginManager gives you a way
to look up plugins by category. Different plugin categories are instantiated
differently (in 2.x), with the "Core" category plugins using the PluginBuilder
class (and related visitors) along with constraint validators supported
directly in PluginBuilder. The key point of confusion, I think, is that
PluginBuilder is only used for Core category plugins. In 3.0, I've overhauled
every category of plugin to support generic dependency injection (which even
includes things such as the node visitors, constraint validators, and
essentially anything that can be created by Injector; the main limitations
there would revolve around startup ordering in that it's difficult to depend on
something that depends on the thing you're already making unless you introduce
a Supplier indirection). This also means that constraint validators are
supported on all plugins in 3.0.
If you're looking to support constraints in more plugin categories in 2.x,
those would need to be done piecemeal.
> ConstraintValidator's are not employed by PluginManager
> ---
>
> Key: LOG4J2-3497
> URL: https://issues.apache.org/jira/browse/LOG4J2-3497
> Project: Log4j 2
> Issue Type: Bug
> Components: Plugins
>Reporter: Volkan Yazici
>Assignee: Matt Sicker
>Priority: Major
> Fix For: 2.18.0
>
>
> {{ConstraintValidator}}'s are not taken into account when plugins are
> collected via {{PluginManager}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (LOG4J2-3502) Add JPMS support for JsonTemplateLayout
Volkan Yazici created LOG4J2-3502: - Summary: Add JPMS support for JsonTemplateLayout Key: LOG4J2-3502 URL: https://issues.apache.org/jira/browse/LOG4J2-3502 Project: Log4j 2 Issue Type: Improvement Components: JsonTemplateLayout Reporter: Volkan Yazici Fix For: 3.0.0 The list of things to be done are as follows: # Create src/main/java/module-info.java in log4j-jtl module # Remove automatic module from log4j-jtl/pom.xml # Create log4j-jtl-test module ## Move log4j-jtl/src/test to log4j-jtl-test/src/test ## Move utility classes from src/test to src/main ## Move all classes from .jtl package to .jtl.test package ## Update log4j-jtl-test/pom.xml to reflect the package path change ## Fix log4j-jtl testJar dependency in log4j-perf -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (LOG4J2-3502) Add JPMS support for JsonTemplateLayout
[ https://issues.apache.org/jira/browse/LOG4J2-3502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volkan Yazici reassigned LOG4J2-3502: - Assignee: Volkan Yazici > Add JPMS support for JsonTemplateLayout > --- > > Key: LOG4J2-3502 > URL: https://issues.apache.org/jira/browse/LOG4J2-3502 > Project: Log4j 2 > Issue Type: Improvement > Components: JsonTemplateLayout >Reporter: Volkan Yazici >Assignee: Volkan Yazici >Priority: Major > Fix For: 3.0.0 > > > The list of things to be done are as follows: > # Create src/main/java/module-info.java in log4j-jtl module > # Remove automatic module from log4j-jtl/pom.xml > # Create log4j-jtl-test module > ## Move log4j-jtl/src/test to log4j-jtl-test/src/test > ## Move utility classes from src/test to src/main > ## Move all classes from .jtl package to .jtl.test package > ## Update log4j-jtl-test/pom.xml to reflect the package path change > ## Fix log4j-jtl testJar dependency in log4j-perf -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (LOG4J2-3497) ConstraintValidator's are not employed by PluginManager
[
https://issues.apache.org/jira/browse/LOG4J2-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532880#comment-17532880
]
Volkan Yazici commented on LOG4J2-3497:
---
{quote}PluginManager's sole job is to keep track of Plugins by category. It
doesn't instantiate plugin instances so it has no knowledge of the data used in
a specific plugin reference.
{quote}
Okay, I see your point {{PluginManager}} is simply a registry of discovered
plugins. Any {{{}@Plugin-{}}}annotated class in the classpath is registered by
this class and it will do nothing else. Right? If so, 1) what is the difference
between {{PluginManager}} and {{PluginRegistry}} and 2) who is responsible for
performing {{ConstraintValidator}} checks?
> ConstraintValidator's are not employed by PluginManager
> ---
>
> Key: LOG4J2-3497
> URL: https://issues.apache.org/jira/browse/LOG4J2-3497
> Project: Log4j 2
> Issue Type: Bug
> Components: Plugins
>Reporter: Volkan Yazici
>Assignee: Matt Sicker
>Priority: Major
> Fix For: 2.18.0
>
>
> {{ConstraintValidator}}'s are not taken into account when plugins are
> collected via {{PluginManager}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-3496) Support injection via container types
[
https://issues.apache.org/jira/browse/LOG4J2-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532861#comment-17532861
]
Volkan Yazici commented on LOG4J2-3496:
---
{quote}I don't see how the injection system can be used with
PatternLayout{quote}
Imagine how you would do this if it would have been a Spring application. In
the current situation, {{PatternLayout}} creates a {{PatternParser}} which
internally collects {{PatternConverter}}'s via direct call to
{{PluginManager}}. With the proposed enhancement, {{PatternLayout}} builder
accepts a {{PatternParserFactory}} instead and that {{PatternParserFactory}}
has a builder containing a field of type {{Map}}.
Here the plugin infra populates {{PatternConverter}}'s, uses it to create a new
{{PatternParserFactory}}, and uses it to create a {{PatternLayout}}.
{quote}PatternParser runs through all the PatternConverter plugins and adds
them to a Map with the pattern converter symbol as the key and the converter
Class as the value. It then parses the pattern and creates a list of
PatternConverters in the order they are specified in the input.{quote}
Exactly and there is no way of changing this behavior, since it is hardcoded.
That is whole point of inversion-of-control (IoC) Ralph, right? You separate
the concerns of constructing objects and using them.
{quote}If all you are thinking of doing is the mapping from the plugins into
the Map of keys to converters, well ok. But I don't see a huge amount of value
in that.{quote}
The whole point of this practicing IoC throughout the entire code base,
whenever necessary. I am not telling every single spot using {{Instant.now()}}
should be first injected an {{Instant}} and use that. All I am saying is
plugins are there for IoC and should be used with that in mind. If random
components circumvent the plugin mechanism and indirectly access to that... It
is like a Spring bean creating its own {{ApplicationContext}} and using it to
populate its own dependencies. I don't know how else to make this more clear.
> Support injection via container types
> -
>
> Key: LOG4J2-3496
> URL: https://issues.apache.org/jira/browse/LOG4J2-3496
> Project: Log4j 2
> Issue Type: New Feature
> Components: Plugins
>Reporter: Volkan Yazici
>Assignee: Matt Sicker
>Priority: Major
> Fix For: 3.0.0
>
>
> Plugin system should support the injection via container types. Since this is
> not currently the case, whenever a, for instance, collection of plugins need
> to be injected (e.g., Pattern and JSON Template Layouts), ad-hoc access to
> {{PluginManager}} or {{PluginUtils}} is needed. This approach has certain
> drawbacks:
> * Duplication of ad-hoc code
> * Not aligned with the way plugins are loaded, that is, via {{@Inject}}
> * Impossible to test
> h3. Container types
> Ideally, the plugin system should support injection via the following
> container types:
> * {{Optional}}
> * {{Collection}}
> * {{Iterable}}
> * {{Set}}
> * {{Stream}}
> * {{List}}
> * {{Map}}
> Above {{P}} denotes the type the plugin is assignable from and {{N}} denotes
> the plugin name.
> h3. Ordering problem
> A {{@PluginOrder}} annotation needs to be introduced to address the following
> corner cases:
> * In the case of {{Optional}}, if there are multiple matches, the first
> one needs to be picked.
> * In the case of collection and map types, elements need to be sorted.
> Sorting can be done in the following way:
> * If one or more of the matches are annotated with {{@PluginOrder}}, they
> will have the precedence and get sorted according to {{@PluginOrder}} values.
> * The rest will be sorted according to their discovery order.
> The order in collection types can be preserved using the following
> implementations:
> * {{Set}} -> {{LinkedHashSet}}
> * {{Map}} -> {{LinkedHashMap}}
> * {{Collection}}, {{Iterable}}, {{Stream}} -> {{List}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (LOG4J2-3501) AsyncWebApplicationLogAppender is unable to write primary appenders. queue is full
ideaboost created LOG4J2-3501: - Summary: AsyncWebApplicationLogAppender is unable to write primary appenders. queue is full Key: LOG4J2-3501 URL: https://issues.apache.org/jira/browse/LOG4J2-3501 Project: Log4j 2 Issue Type: Question Environment: linux java 11 log4j 2.17.0 Reporter: ideaboost Upgrade from 2.16.x to 2.17.0 Sometime logs are failed to write with below error: *AsyncWebApplicationLogAppender is unable to write primary appenders. queue is full* -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (LOG4J2-3500) Deadlock in Log4j
[ https://issues.apache.org/jira/browse/LOG4J2-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532762#comment-17532762 ] Gary D. Gregory commented on LOG4J2-3500: - Hello [~G1G4] 2.12.1 is a pretty old version. Would you be able to test on the current version 2.17.2? > Deadlock in Log4j > - > > Key: LOG4J2-3500 > URL: https://issues.apache.org/jira/browse/LOG4J2-3500 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.12.1 >Reporter: Gianfranco Amatore >Priority: Major > Attachments: tdump.2022-03-31 13_10_15.out > > > I encountered a problem on our ESB (Red Hat Fuse 7.6), it seems that the > log4j dead locked while writing the log file. The whole jvm remains blocked > for about 10 mins, then it starts again executing. Attached the thread-dump > that shows the deadlock. > > > > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (LOG4J2-3500) Deadlock in Log4j
Gianfranco Amatore created LOG4J2-3500: -- Summary: Deadlock in Log4j Key: LOG4J2-3500 URL: https://issues.apache.org/jira/browse/LOG4J2-3500 Project: Log4j 2 Issue Type: Bug Components: Core Affects Versions: 2.12.1 Reporter: Gianfranco Amatore Attachments: tdump.2022-03-31 13_10_15.out I encountered a problem on our ESB (Red Hat Fuse 7.6), it seems that the log4j dead locked while writing the log file. The whole jvm remains blocked for about 10 mins, then it starts again executing. Attached the thread-dump that shows the deadlock. -- This message was sent by Atlassian Jira (v8.20.7#820007)
