riginal Message-----
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".
lease keep us posted!
Hope this helps,
Remko
____
From: "SMITH, CURTIS"
To: "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 performa
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 jumped
>> 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
assLoaderContextSelector
will be of any benefit to you over 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 t
r
> 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.
t 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
o you use the
pattern formats that are now available in log4j-2.0?
Regards,
Remko
From: "SMITH, CURTIS"
To: Log4J Users List
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 obviou
Only 1 thread can be active 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 wrot
ny guesses for me to try?
Tnx curt
_________
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 l
s 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. name="abc" I see the name I need to use now.
>
> My 2nd part of this question is, why should I em
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
7;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:
> Programmatic
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
O
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
-Orig
My testing of log4j v2 just started getting my log output to my log files, but
had
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 reflection... I hope nothing internal is now goin
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
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 system
>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 t
>From a thread back in May:
My question to the below snips of the thread are;
My app has many Appenders (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 (??) ?
Thanks, cur
Ralph
20 matches
Mail list logo
