[jira] [Commented] (LOG4J2-1435) Log4j2 writing logs to already rolled file

[ https://issues.apache.org/jira/browse/LOG4J2-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335699#comment-15335699 ] Prashant commented on LOG4J2-1435: -- 1. We have mandate requirement to upgrade to log4j 2

[jira] [Commented] (LOG4J2-1435) Log4j2 writing logs to already rolled file

[ https://issues.apache.org/jira/browse/LOG4J2-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335766#comment-15335766 ] Remko Popma commented on LOG4J2-1435: - Log4j 2 is a complete rewrite and works differ

[jira] [Commented] (LOG4J2-1434) StringBuffer in ThreadLocal can cause excessive memory usage after large log messages

[ https://issues.apache.org/jira/browse/LOG4J2-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335798#comment-15335798 ] Remko Popma commented on LOG4J2-1434: - Great that you are benchmarking to get an idea

[jira] [Comment Edited] (LOG4J2-1434) StringBuffer in ThreadLocal can cause excessive memory usage after large log messages

[ https://issues.apache.org/jira/browse/LOG4J2-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335798#comment-15335798 ] Remko Popma edited comment on LOG4J2-1434 at 6/17/16 9:46 AM: -

[jira] [Comment Edited] (LOG4J2-1434) StringBuffer in ThreadLocal can cause excessive memory usage after large log messages

[ https://issues.apache.org/jira/browse/LOG4J2-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335798#comment-15335798 ] Remko Popma edited comment on LOG4J2-1434 at 6/17/16 9:56 AM: -

[jira] [Comment Edited] (LOG4J2-1435) Log4j2 writing logs to already rolled file

[ https://issues.apache.org/jira/browse/LOG4J2-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335766#comment-15335766 ] Remko Popma edited comment on LOG4J2-1435 at 6/17/16 10:09 AM:

ParameterFormatter.countArgumentPlaceholders methods

These methods are confusing org.apache.logging.log4j.message.ParameterFormatter.countArgumentPlaceholders(String) org.apache.logging.log4j.message.ParameterFormatter.countArgumentPlaceholders2(String, int[]) org.apache.logging.log4j.message.ParameterFormatter.countArgumentPlaceholders3(char[], int

Re: ParameterFormatter.countArgumentPlaceholders methods

+1 to not putting numbers in the method names. On 17 June 2016 at 11:53, Gary Gregory wrote: > These methods are confusing > > > org.apache.logging.log4j.message.ParameterFormatter.countArgumentPlaceholders(String) > org.apache.logging.log4j.message.ParameterFormatter.countArgumentPlaceholders2(

Build failed in Jenkins: Log4j 2.x #2039

See Changes: [ggregory] Don't hide ivar name. [ggregory] Don't need these parens. [ggregory] Add final modifier to lvar. [ggregory] Alawys use a block. [ggregory] Add missing '@Override' annotations. [ggregory] Remove unused imports.

Scala API and flow tracing

I am looking at how to do flow tracing in the Scala API I am working on. It is a bit tricky since a lot of the logic is in AbstractLogger which I have no access to. (Quick Scala intro: types goes after variables/methods/parameters, Unit is like void in Java, AnyRef is like Object in Java, the *

Scala API and parameters

Implementing support for parameterized messages is tricky in Scala since Scala cannot properly handle the var-args overloads in Logger and MessageFactory. Given that you can use string interpolations, how important is it to be able to use Log4j parameters? https://github.com/apache/logging-log4j2

NameAbbreviator.MaxElementAbbreviator.getMinCount(Strategy)

Should this: private int getMinCount(final Strategy strategy) { if (Strategy.DROP == strategy) { return 0; } else { // Strategy.RETAIN return 1; } } be: private int getMinCount(final Strategy strategy) {

Efficient location information in Scala

This seems like a nice way to get location information efficiently in Scala: https://github.com/lihaoyi/sourcecode It is based on macros, so it won't work for Java. Can I pass this in from the Scala API somehow? -- [image: MagineTV] *Mikael Ståldal* Senior software developer *Magine TV* mikae

Build failed in Jenkins: Log4j 2.x #2040

See Changes: [ggregory] Statement unnecessarily nested within else clause. -- [...truncated 4380 lines...] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.732 sec - in org.apache.

Jenkins build is unstable: Log4j 2.x #2041

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Comment Edited] (LOG4J2-1434) StringBuffer in ThreadLocal can cause excessive memory usage after large log messages

[ https://issues.apache.org/jira/browse/LOG4J2-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337167#comment-15337167 ] Luke Butters edited comment on LOG4J2-1434 at 6/17/16 10:56 PM: ---

[jira] [Commented] (LOG4J2-1434) StringBuffer in ThreadLocal can cause excessive memory usage after large log messages

[ https://issues.apache.org/jira/browse/LOG4J2-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337167#comment-15337167 ] Luke Butters commented on LOG4J2-1434: -- Yes I have experienced problems in micro ben

[jira] [Commented] (LOG4J2-1434) StringBuffer in ThreadLocal can cause excessive memory usage after large log messages

[ https://issues.apache.org/jira/browse/LOG4J2-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337187#comment-15337187 ] Luke Butters commented on LOG4J2-1434: -- Note that my assumption is we want to rememb

Re: NameAbbreviator.MaxElementAbbreviator.getMinCount(Strategy)

Yes, your suggestion is better. Not only cleaner, but also more performant: in the first case the cpu will speculatively execute both branches. One of them will fail and that execution pipeline will be discarded. Not a big deal, happens all the time, and branch prediction is very good these day

[jira] [Commented] (LOG4J2-1430) Add optional support for Conversant DisruptorBlockingQueue in AsyncAppender

[ https://issues.apache.org/jira/browse/LOG4J2-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337239#comment-15337239 ] Matt Sicker commented on LOG4J2-1430: - Alright, I've converted BlockingQueueFactory i

Re: NameAbbreviator.MaxElementAbbreviator.getMinCount(Strategy)

On Fri, Jun 17, 2016 at 4:25 PM, Remko Popma wrote: > Yes, your suggestion is better. > Not only cleaner, but also more performant: in the first case the cpu will > speculatively execute both branches. One of them will fail and that > execution pipeline will be discarded. Not a big deal, happens

Jenkins build is still unstable: Log4j 2.x #2042

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Comment Edited] (LOG4J2-1430) Add optional support for Conversant DisruptorBlockingQueue in AsyncAppender

[ https://issues.apache.org/jira/browse/LOG4J2-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337239#comment-15337239 ] Matt Sicker edited comment on LOG4J2-1430 at 6/18/16 12:23 AM:

[jira] [Commented] (LOG4J2-1430) Add optional support for Conversant DisruptorBlockingQueue in AsyncAppender

[ https://issues.apache.org/jira/browse/LOG4J2-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337344#comment-15337344 ] Matt Sicker commented on LOG4J2-1430: - Updates on configurability: * Converted Block

Guideline for @Ignore

The test org.apache.logging.log4j.core.appender.FileAppenderTest.testMultipleVMs() is @Ignore'd but it works fine on my machine. If it had a description, then we'd know what the intent is, for example: @Ignore("This does not work in Jenkins on full moons") Gary -- E-Mail: garydgreg...@gmail.co

[jira] [Commented] (LOG4J2-1434) StringBuffer in ThreadLocal can cause excessive memory usage after large log messages

[ https://issues.apache.org/jira/browse/LOG4J2-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337380#comment-15337380 ] Remko Popma commented on LOG4J2-1434: - Where possible I prefer not to store non-JDK c

Jenkins build is back to stable : Log4j 2.x #2043

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: logging-log4j2 git commit: Make fairness configurable in ArrayBlockingQueueFactory

Is there any reason to expose fairness as a user configurable parameter? The thing is that it sounds like a good thing (so users are likely to switch it on) but actually hampers performance and in our case there's no real reason to require fairness... Sent from my iPhone > On 2016/06/18, at 9

Re: logging-log4j2 git commit: Make fairness configurable in ArrayBlockingQueueFactory

Honestly, the only reason I added it here was because it's available. I do know that concurrency fairness is almost always the wrong thing to do, though. I can remove it. On 17 June 2016 at 20:50, Remko Popma wrote: > Is there any reason to expose fairness as a user configurable parameter? > > T

Re: logging-log4j2 git commit: Make fairness configurable in ArrayBlockingQueueFactory

If you don't mind, let's remove it until a user requests it. I hope I'm not being too negative here. :-) Sent from my iPhone > On 2016/06/18, at 11:08, Matt Sicker wrote: > > Honestly, the only reason I added it here was because it's available. I do > know that concurrency fairness is almost

Re: logging-log4j2 git commit: Revert "Make fairness configurable in ArrayBlockingQueueFactory"

Thanks! Sent from my iPhone > On 2016/06/18, at 11:11, mattsic...@apache.org wrote: > > Repository: logging-log4j2 > Updated Branches: > refs/heads/feature/LOG4J2-1430 bf997fc10 -> 604306cc8 > > > Revert "Make fairness configurable in ArrayBlockingQueueFactory" > > This reverts commit bf997f

Re: logging-log4j2 git commit: Make fairness configurable in ArrayBlockingQueueFactory

Not at all; I think you're right. It's a confusing option. On 17 June 2016 at 21:17, Remko Popma wrote: > If you don't mind, let's remove it until a user requests it. I hope I'm > not being too negative here. :-) > > Sent from my iPhone > > On 2016/06/18, at 11:08, Matt Sicker wrote: > > Honest

Re: logging-log4j2 git commit: Make fairness configurable in ArrayBlockingQueueFactory

On Fri, Jun 17, 2016 at 7:17 PM, Remko Popma wrote: > If you don't mind, let's remove it until a user requests it. I hope I'm > not being too negative here. :-) > Agreed. Thank you Matt for putting in the work but this one might fall in the YAGNI category ;-) Gary > Sent from my iPhone > > On

[jira] [Commented] (LOG4J2-1430) Add optional support for Conversant DisruptorBlockingQueue in AsyncAppender

[ https://issues.apache.org/jira/browse/LOG4J2-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337553#comment-15337553 ] Matt Sicker commented on LOG4J2-1430: - Some updated AsyncAppender benchmarks from a d

[jira] [Commented] (LOG4J2-1434) StringBuffer in ThreadLocal can cause excessive memory usage after large log messages

[ https://issues.apache.org/jira/browse/LOG4J2-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337571#comment-15337571 ] Ralph Goers commented on LOG4J2-1434: - This seems like it is getting more and more co

[jira] [Commented] (LOG4J2-1430) Add optional support for Conversant DisruptorBlockingQueue in AsyncAppender

[ https://issues.apache.org/jira/browse/LOG4J2-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337572#comment-15337572 ] Ralph Goers commented on LOG4J2-1430: - Honestly, there are so many numbers here that

Jenkins build became unstable: Log4j 2.x #2044

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1434) StringBuffer in ThreadLocal can cause excessive memory usage after large log messages

[ https://issues.apache.org/jira/browse/LOG4J2-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337591#comment-15337591 ] Remko Popma commented on LOG4J2-1434: - Aha! Are you thinking of revisiting LOG4J2-111

[jira] [Commented] (LOG4J2-1430) Add optional support for Conversant DisruptorBlockingQueue in AsyncAppender

[ https://issues.apache.org/jira/browse/LOG4J2-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337600#comment-15337600 ] Remko Popma commented on LOG4J2-1430: - What is the thread count for this test? Also,