[ 
https://issues.apache.org/jira/browse/LOG4J2-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002872#comment-16002872
 ] 

ASF GitHub Bot commented on LOG4J2-1874:
----------------------------------------

Github user remkop commented on the issue:

    https://github.com/apache/logging-log4j2/pull/71
  
    @leventov Thanks for the quick turnaround. Today I only had time to check 
that the tests pass, but I ran `mvn clean install` twice and both times it 
failed here:
    
    ```
    [ERROR] Tests run: 23, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
0.075 s <<< FAILURE! - in org.apache.logging.log4j.core.layout.PatternLayoutTest
    [ERROR] 
testPatternSelector(org.apache.logging.log4j.core.layout.PatternLayoutTest)  
Time elapsed: 0.056 s  <<< FAILURE!
    java.lang.AssertionError:
    Unexpected result: 2017-05-10 00:17:21,574 TRACE [main]: ====== 
PatternLayoutTest.testPatternSelector:259 entry ======
    
            at 
org.apache.logging.log4j.core.layout.PatternLayoutTest.testPatternSelector(PatternLayoutTest.java:261)
    ```


> Add ByteBufferDestionation.write(ByteBuffer) and write(byte[], int, int) 
> methods and call them from TextEncoderHelper whenever possible
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-1874
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1874
>             Project: Log4j 2
>          Issue Type: Improvement
>            Reporter: Roman Leventov
>            Assignee: Remko Popma
>
> Existing ByteBufferDestination API: getByteBuffer() and drain() is designed 
> so that synchronization couldn't be avoided. This doesn't allow to implement 
> LOG4J2-928.
> Github PR: https://github.com/apache/logging-log4j2/pull/71
> Added methods: write(ByteBuffer data) and write(byte[] data, int offset, int 
> length) are designed so that they should care about synchronization 
> themselves, internally, if needed. They should also synchronize with possible 
> concurrent users of the synchronized getByteBuffer() + drain() API. 
> Nevertheless, it allows for ByteBufferDestination implementations to 
> implement write() methods without lock-free.
> TextEncoderHelper (hence StringBuilderEncoder, which delegates it's logic to 
> TextEncoderHelper) is changed so that it calls ByteBufferDestination.write() 
> whenever possible.  There is an expectation that most of encoded events fit 
> the thread-local buffers, and write() could be called instead of writing to 
> destination.getByteBuffer() with synchronization.
> The PR also includes a sanity improvement: uses ByteBuffer.arrayOffset() at 
> some places.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to