From a thread back in May:
My question to the below snips of the thread are;
My app has many Catagories (using 1.x terminology). To setLevel in 1.x I had
to getCurrentCatagories() and iterate over the list setting level.
In 2.x, does the code below set all Appenders regardless of what Level
http://logging.apache.org/log4j/2.x/manual/async.html
This URL describes that v2 has both async logger and async appender. What is
the suggested config for an embedded situation where I want low latency,
nothing fancy?
I've had do this in code since we don't own the cmd line: OSGi and
I feel apologetic for asking how to debug a v2 configuration but there's no
links off the v2 website. My env is embedded and I'm not getting any missing
classpath problems, I solved those. I am getting console output but none of my
FastRollingFile appenders are emitting their logs.
Some of
My testing of log4j v2 just started getting my log output to my log files, but
had configuration status=trace level=trace
I googled and found this no reflection log to stdout is from log4j2. :)
This is an embedded env; IBM J9 J2ME jdk 1.6 on single core Arm chip, but I
guess no
If a sequence of execution for a user follows is handled by one thread (often
the case in j2ee) then look at fish tagging, MDC. Log4j2 can put user and
any other context in a thread Local object behind the scenes.
http://logging.apache.org/log4j/2.x/manual/thread-context.html
curt
Programmatical setting of loggers only works for the first logger declared
unfortunately. Further there's a missing API that allows me to get a list of
loggers (or configurations) to walk and set level like get Category in v1. See
my code below that has coupling between code and log4j2.xml
. You don't have any loggers configured named VIDEO, DLA
or DEVICES. You do have appenders with those names. All those
getLoggerConfig calls should end up returning the root loggerConfig.
Ralph
On Jul 25, 2013, at 2:36 PM, SMITH, CURTIS wrote:
Programmatical setting of loggers only works
I suspect a slow single core env is a new scenario for v2 and async logger.
My view is that there's a mis match between v2's async logger thread design
that works great on multi-core envs and this embedded slow single core env...
Sooo I need to try a few different configurations to see what
() call that returns a Map of all the LoggerConfig objects.
Ralph
On Jul 26, 2013, at 6:51 AM, SMITH, CURTIS wrote:
Oh! So you're right. That's what feed back is for.logger
name=abc I see the name I need to use now.
My 2nd part of this question is, why should I embed into code
_
From: SMITH, CURTIS
Sent: Friday, July 26, 2013 1:16 PM
To: log4j-user@logging.apache.org
Subject: async logger on slow single core env performs 50% worse than log4j v1
I suspect a slow single core env is a new scenario for v2 and async logger.
My view is that there's a mis
at a
time so when you switch threads the active thread will just stop. This won't
gain you any additional throughput but you will still incur the additional
overhead of thread management and locking.
Ralph
On Jul 26, 2013, at 1:55 PM, SMITH, CURTIS wrote:
I removed System.setProperty
From: SMITH, CURTIS cs0...@att.com
To: Log4J Users List log4j-user@logging.apache.org
Sent: Saturday, July 27, 2013 6:55 AM
Subject: RE: async logger on slow single core env performs 50% worse than log4j
v1
LOL well that's obvious now. :) It was more a case of wishful thinking and
why
From: SMITH, CURTIS cs0...@att.com
To: Log4J Users List log4j-user@logging.apache.org
Sent: Saturday, July 27, 2013 6:55 AM
Subject: RE: async logger on slow single core env performs 50% worse than log4j
v1
LOL well that's obvious now. :) It was more a case of wishful thinking
BasicContextSelector
as you are unlikely to have need for multiple LoggerContexts.
Ralph
On Jul 29, 2013, at 7:08 AM, SMITH, CURTIS wrote:
Hi guys, I mentioned this observation last week, that my embedded single
core env, the VM also does not support reflection. Is reflection used
BasicContextSelector.
On Jul 29, 2013, at 9:05 AM, SMITH, CURTIS wrote:
Ralph, Was your comment about BasicContextSelector me and my quest to get V2
to run as well as V1 on my slow single core J2ME env?
My test run with AsyncLogger blew up. This J2ME VM does not have reflection.
Guessing
Are the test programs identical? I
Yes identical excepting for log4j versions and the required totally different
way of configuring.
MDC
Not coded this yet, wanting to in one version or the other. So no code to post
since I haven't gotten to MDC vs NDC (??) yet. Just making sure going to
Greetings,
A terse recap of performance on my J2ME on a slow single core env:
BasicContextSelector and BufferedIO=false for RollingFile DOES seem to equal
log4j v1 performance in my most recent benchmarks. I'm not comfortable with
this result because what happened is the V1 benchmarks
!
Hope this helps,
Remko
From: SMITH, CURTIS cs0...@att.com
To: log4j-user@logging.apache.org log4j-user@logging.apache.org
Sent: Thursday, August 1, 2013 10:54 PM
Subject: use of ThreadContext cleanup vs memory leaks etc
Greetings,
A terse recap of performance
-
From: SMITH, CURTIS
Sent: Friday, July 26, 2013 5:55 PM
To: Log4J Users List
Subject: RE: async logger on slow single core env performs 50% worse than log4j
v1
LOL well that's obvious now. :) It was more a case of wishful thinking and
why not give it a try.But it's still odd that my
19 matches
Mail list logo
