You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Remko Popma (JIRA)" <ji...@apache.org> on 2016/04/26 18:53:12 UTC
[jira] [Comment Edited] (LOG4J2-1295) Automated testing to verify
no temporary objects allocated in gc-free configuration
[ 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: remkop@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org