[
https://issues.apache.org/jira/browse/LOG4J2-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15258437#comment-15258437
]
Remko Popma edited comment on LOG4J2-1295 at 4/26/16 4:53 PM:
--------------------------------------------------------------
Our GcFreeMixedSyncAyncLoggingTest test randomly fail with this exception:
{code}
org.junit.ComparisonFailure:
Exception in thread "Thread-0" java.lang.NullPointerException
at
com.google.monitoring.runtime.instrumentation.AllocationRecorder.getObjectSize(AllocationRecorder.java:200)
at
com.google.monitoring.runtime.instrumentation.AllocationRecorder.recordAllocation(AllocationRecorder.java:244)
at java.util.Hashtable.getEnumeration(Hashtable.java:665)
at java.util.Hashtable.keys(Hashtable.java:329)
at
java.util.logging.LogManager$LoggerContext.getLoggerNames(LogManager.java:688)
at java.util.logging.LogManager.reset(LogManager.java:1135)
at java.util.logging.LogManager$Cleaner.run(LogManager.java:248)
expected:<[FATAL o.a.l.l.c.GcFreeMixedSyncAyncLoggingTest [main] This message
is logged to the console]> but was:<[Exception in thread "Thread-0"
java.lang.NullPointerException]>
at
org.apache.logging.log4j.core.GcFreeMixedSyncAyncLoggingTest.testNoAllocationDuringSteadyStateLogging(GcFreeMixedSyncAyncLoggingTest.java:31)
{code}
I believe this is a bug in AllocationRecorder: and raised this issue:
https://github.com/google/allocation-instrumenter/issues/15
was (Author: rem...@yahoo.com):
Our tests randomly fail with this exception:
{code}
Exception in thread "Thread-0" java.lang.NullPointerException
at
com.google.monitoring.runtime.instrumentation.AllocationRecorder.getObjectSize(AllocationRecorder.java:200)
at
com.google.monitoring.runtime.instrumentation.AllocationRecorder.recordAllocation(AllocationRecorder.java:244)
at java.util.Hashtable.getEnumeration(Hashtable.java:665)
at java.util.Hashtable.keys(Hashtable.java:329)
at
java.util.logging.LogManager$LoggerContext.getLoggerNames(LogManager.java:688)
at java.util.logging.LogManager.reset(LogManager.java:1135)
at java.util.logging.LogManager$Cleaner.run(LogManager.java:248)
{code}
I believe this is a bug in AllocationRecorder: and raised this issue:
https://github.com/google/allocation-instrumenter/issues/15
> Automated testing to verify no temporary objects allocated in gc-free
> configuration
> -----------------------------------------------------------------------------------
>
> Key: LOG4J2-1295
> URL: https://issues.apache.org/jira/browse/LOG4J2-1295
> Project: Log4j 2
> Issue Type: New Feature
> Components: API, Configurators, Core, Layouts, Pattern Converters
> Affects Versions: 2.5
> Reporter: Remko Popma
> Assignee: Remko Popma
> Fix For: 2.6
>
>
> LOG4J2-1270 proposes changes to support gc-free behaviour (no allocation of
> temporary objects) in certain configurations.
> This ticket is about verifying that Log4j does not allocate in these
> configurations. It is not always obvious that some code creates objects, so
> it is easy for regressions to creep in during maintenance code changes.
> Ideally this verification is packaged so it can run automatically during the
> test phase of the build, for example in a JUnit test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
