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 Jess Holle <je...@ptc.com> on 2005/12/01 16:22:06 UTC
Log4j and Java 5
Has anyone tried replacing the synchronization in log4j with Java 5
locks to and done any benchmarks?
I'm curious as I think it would be interesting to have a lock factory
which produces something like the existing locks for pre-Java-5 JVMs and
Java 5 locks in Java 5.
We purely use and require Java 5 and higher for all new development at
this point, which may make us unusual, but that's where we're at. I
understand the need to support earlier JVMs, but am interested in
squeezing the best possible performance and scalability out under Java 5.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4jMini/log4jME
Posted by Yoav Shapira <yo...@computer.org>.
Ralph,
You're doing the right thing to get this project moving: all it takes
is one person who's interested and willing to contribute patches.
Update the relevant Bugzilla issues you list below and open new ones
if needed. We'll look at the patches and commit them, hopefully
quickly...
Yoav
On 12/1/05, Ralph Curtis <ra...@gabrielsoftware.com> wrote:
> Hi Yoav,
>
> Turns out there is already a bug report on this issue (#29719). A fix was
> posted back in June 2004. Most embarassing is that I actually commented on
> it in May 2005 - and then forgot about it - when I was at Symbium. So the
> fix is there for over a year but the project seems to be orphaned.
>
> I have another version with a lot of changes (Category replaced by Logger)
> that I would like to see replace the current version in the repository. How
> do we get this log4jMini project moving again? Any suggestions?
>
> Ralph
>
>
> -----Original Message-----
> From: yoavshapira@gmail.com [mailto:yoavshapira@gmail.com] On Behalf Of Yoav
> Shapira
> Sent: Thursday, December 01, 2005 12:16
> To: Log4J Developers List; ralph.curtis@gabrielsoftware.com
> Subject: Re: log4jMini/log4jME
>
>
> Ralph,
> Thanks for contributing these changes and reporting them. You can open a
> new Bugzilla issue (http://issues.apache.org/bugzilla),
> selecting log4j as the product and describing your work. You can then
> attach diff files comparing your patch to the existing files: use the diff
> -u format. Thanks,
>
> Yoav
>
>
> On 12/1/05, Ralph Curtis <ra...@gabrielsoftware.com> wrote:
> > I hope this is the right place to ask this question...
> >
> > I checked out the latest version (v1_3alpha_6) for this J2ME
> > (Foundation/J9) log4j implementation. Found it doesn't build. I fixed
> > the build problems and would like to get the changes checked in. I am
> > not a contributor to date. Can someone direct me to info on how to get
> > my fixes contributed?
> >
> > Ralph
> >
> > PS
> > I have also created another version using a Logger class - instead of
> > Category - for greater compatability with the main log4j project. I
> > would like to see about getting that checked in as well.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
>
>
> --
> Yoav Shapira
> System Design and Management Fellow
> MIT Sloan School of Management
> Cambridge, MA, USA
> yoavs@computer.org / www.yoavshapira.com
>
>
>
--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4jMini/log4jME
Posted by Yoav Shapira <yo...@apache.org>.
Ralph,
Thanks for contributing these changes and reporting them. You can
open a new Bugzilla issue (http://issues.apache.org/bugzilla),
selecting log4j as the product and describing your work. You can then
attach diff files comparing your patch to the existing files: use the
diff -u format. Thanks,
Yoav
On 12/1/05, Ralph Curtis <ra...@gabrielsoftware.com> wrote:
> I hope this is the right place to ask this question...
>
> I checked out the latest version (v1_3alpha_6) for this J2ME (Foundation/J9)
> log4j implementation. Found it doesn't build. I fixed the build problems and
> would like to get the changes checked in. I am not a contributor to date.
> Can someone direct me to info on how to get my fixes contributed?
>
> Ralph
>
> PS
> I have also created another version using a Logger class - instead of
> Category - for greater compatability with the main log4j project. I would
> like to see about getting that checked in as well.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j and Java 5
Posted by Jess Holle <je...@ptc.com>.
Paul Smith wrote:
>> I guess what I was thinking was an incremental approach in 1.3 that
>> does not break backwards compatibility. [I'd think that would be a
>> better use of time/energy than the Priority vs. Level and Category
>> vs. Logger mess...]
>
> I'm against requiring Java 5 for log4j 1.3. 2.0 though is fine.
I was never suggesting requiring it -- only leveraging it where
possible. [I'm not *that* self-centered.]
> Originally log4j 1.3 was going to only require JDK 1.2! But we've
> taken so long that I think we should probably revisit what we will
> require. Even JDK 1.3 is getting long in the tooth.
>
> I think we need to get a discussion going as to finalizing what our
> plans are for 1.3, because we're just drifting at the moment.
I started writing loads of code against 1.2.x about a year ago expecting
that I'd get to upgrade to a 1.3 "final" in a few months this entire
time. From where I sit it certainly seems like 1.3 is drifting -- there
haven't been any clear signs of progress to those primarily focused on
1.2 in that time.
> As an aside, Jess be reminded that a lot of Apache folks are at
> ApacheCon soon, so don't take it personally if there is a quiet
> response at the mometn. (I'm in Australia, wishing I was at
> ApacheCon.. :( )
I'm not taking it personally. If I was as blunt as I am and took things
personally I'd be in a real sorry state most of the time.
Thanks for pointing out that folk are busy with ApacheCon, however, as I
really was worried that the log4j development community was this sleepy
that loud, obnoxious raising of serious issues didn't stir too much
response or immediate action. Putting this in context with ApacheCon
put a bit more hopeful spin on things...
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j and Java 5
Posted by Paul Smith <ps...@aconex.com>.
>
> I guess what I was thinking was an incremental approach in 1.3 that
> does not break backwards compatibility. [I'd think that would be a
> better use of time/energy than the Priority vs. Level and Category
> vs. Logger mess...]
I'm against requiring Java 5 for log4j 1.3. 2.0 though is fine.
Originally log4j 1.3 was going to only require JDK 1.2! But we've
taken so long that I think we should probably revisit what we will
require. Even JDK 1.3 is getting long in the tooth.
I think we need to get a discussion going as to finalizing what our
plans are for 1.3, because we're just drifting at the moment.
As an aside, Jess be reminded that a lot of Apache folks are at
ApacheCon soon, so don't take it personally if there is a quiet
response at the mometn. (I'm in Australia, wishing I was at
ApacheCon.. :( )
Paul
Re: Log4j and Java 5
Posted by Jess Holle <je...@ptc.com>.
Curt Arnold wrote:
> On Dec 1, 2005, at 9:22 AM, Jess Holle wrote:
>
>> Has anyone tried replacing the synchronization in log4j with Java 5
>> locks to and done any benchmarks?
>>
>> I'm curious as I think it would be interesting to have a lock
>> factory which produces something like the existing locks for pre-
>> Java-5 JVMs and Java 5 locks in Java 5.
>>
>> We purely use and require Java 5 and higher for all new development
>> at this point, which may make us unusual, but that's where we're
>> at. I understand the need to support earlier JVMs, but am
>> interested in squeezing the best possible performance and
>> scalability out under Java 5.
>
> I have suggested targeting Java 5 in log4j 2.0. However, I plan on
> experimenting with substantially reducing the scope of locks in log4j
> 2.0 instead of just incrementally using new locking features with the
> current approach.
I guess what I was thinking was an incremental approach in 1.3 that does
not break backwards compatibility. [I'd think that would be a better
use of time/energy than the Priority vs. Level and Category vs. Logger
mess...]
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j and Java 5
Posted by Elias Ross <er...@m-qube.com>.
On Thu, 2005-12-01 at 10:22 -0600, Curt Arnold wrote:
>
> I have suggested targeting Java 5 in log4j 2.0. However, I plan on
> experimenting with substantially reducing the scope of locks in
> log4j
> 2.0 instead of just incrementally using new locking features with
> the
> current approach.
Again, I just want to second Curt's thought. There's nothing terribly
mystical about the locks that Java 5 versus what Log4j 1.3 uses. If you
can reduce the amount of locking (thereby increasing concurrency) then
you are likely more performance than switching lock implementations.
[As a note, given the amount of existing breakage 1.3 contains, I'm
wondering if the deadlock fix I proposed would be reasonable. 99% of
the users may not even know, even those that extend from the Appender
classes.]
One approach that needs to change to reduce locking, is to reduce object
reuse. For multi-threaded applications, it's better to create new
objects than attempt to reuse existing objects and increase your locking
potential.
Please take a look at this:
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-lnxw01JavaUrbanLegends
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j and Java 5
Posted by Curt Arnold <ca...@apache.org>.
On Dec 1, 2005, at 9:22 AM, Jess Holle wrote:
> Has anyone tried replacing the synchronization in log4j with Java 5
> locks to and done any benchmarks?
>
> I'm curious as I think it would be interesting to have a lock
> factory which produces something like the existing locks for pre-
> Java-5 JVMs and Java 5 locks in Java 5.
>
> We purely use and require Java 5 and higher for all new development
> at this point, which may make us unusual, but that's where we're
> at. I understand the need to support earlier JVMs, but am
> interested in squeezing the best possible performance and
> scalability out under Java 5.
I have suggested targeting Java 5 in log4j 2.0. However, I plan on
experimenting with substantially reducing the scope of locks in log4j
2.0 instead of just incrementally using new locking features with the
current approach.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4jMini/log4jME
Posted by Curt Arnold <ca...@apache.org>.
I've seen log4jMini or log4jME but haven't investigated them and have
been curious about their status, deviations from log4j proper, etc.
Can anyone give a quick overview or a reference. Should we add them
to the Gump builds?
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
log4jMini/log4jME
Posted by Ralph Curtis <ra...@gabrielsoftware.com>.
I hope this is the right place to ask this question...
I checked out the latest version (v1_3alpha_6) for this J2ME (Foundation/J9)
log4j implementation. Found it doesn't build. I fixed the build problems and
would like to get the changes checked in. I am not a contributor to date.
Can someone direct me to info on how to get my fixes contributed?
Ralph
PS
I have also created another version using a Logger class - instead of
Category - for greater compatability with the main log4j project. I would
like to see about getting that checked in as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j and Java 5
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Fri, 2 Dec 2005, Endre St�lsvik wrote:
|
| One more thing about concurrent.jar: if the inclusion of a entirely new
| library dependency sounds bad (which I personally think!), one have the
| option of just "stealing" the parts that are necessary: the magic is not
| in new JVM features, but in a very good engineering using existing. These
| will run _faster_ on newer JVMs, but are just as valid on older.
| " All classes are released to the public domain and may be used for any
| purpose whatsoever without permission or acknowledgment. "
Replying to myself here: one may also just backport the parts of JSR 166
(jse5 java.util.concurrent) that is needed, since these also are
available:
[ http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/ ]
This backport is for 1.4, but that may easily be remedied by making a new
version of the "Utils" class that drops the "nanoseconds" element entirely
- in this case, it can run on 1.2..
This would alleviate the need for introspection wizardy entierly - you get
the exact same as if running on jse5.
Regards,
Endre.
Re: Log4j and Java 5
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Fri, 2 Dec 2005, Yoav Shapira wrote:
| (for example, on the Tomcat mailing lists, we've seen far more JSE5 than
| JDK 1.4 queries not just recently, but for almost two years now),
Do remember that the user base (hopefully!) also is _expanding_, and that
_new_ users (and instances?) probably tend to use "the newest there is",
both on servlet containers and JRE. In addition, when you decide which
Servlet Container to use, a rather low level part of the infrastructure,
you are more probably also in a position to decide which JRE to run on. If
you have to do work on an existing WebSphere system or similar, you will
not be able to decide such things as easily.
One more thing about concurrent.jar: if the inclusion of a entirely new
library dependency sounds bad (which I personally think!), one have the
option of just "stealing" the parts that are necessary: the magic is not
in new JVM features, but in a very good engineering using existing. These
will run _faster_ on newer JVMs, but are just as valid on older.
" All classes are released to the public domain and may be used for any
purpose whatsoever without permission or acknowledgment. "
Regards,
Endre.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j and Java 5
Posted by Jess Holle <je...@ptc.com>.
Yoav Shapira wrote:
>Hi,
>Doug Lea's concurrent library is a good piece of software. We used it
>at my old workplace for a couple of years in heavy apps, never a
>problem. And now it's part of JSE 5 so future migration will be easy.
> One could also imagine a simple class that detects if running on JSE5
>and later and then uses java.util.concurrent, or else uses Doug Lea's
>library.
>
>
Or detects that neither is available and uses something simple -- for a
client-side app with little threading but a requirement for few/small
jars, for instance.
That's really what I was getting at for Java 5 to begin with.
>Requiring JSE5 for log4j is probably not a good idea: one of log4j's
>main advantages over JDK 1.4 logging is its ability to run on older
>JVMs.
>
>
I never argued to *require* JSE5 -- just to take advantage of it
conditionally where appropriate. Yes, that would add an virtual method
call to the stack at a minimum, but that's not much and I was just
wondering aloud if there were cases where that might not be worthwhile.
>That said, JSE5 is not only being rapidly adopted (for example, on the
>Tomcat mailing lists, we've seen far more JSE5 than JDK 1.4 queries
>not just recently, but for almost two years now), but it will be
>required for JEE5 containers. So, for example, Tomcat 6, Jetty 7,
>Geronimo 1.1, Weblogic 10, etc will all require JEE5 or higher as
>their JVM -- the JDK 1.1, 1.2, 1.3, 1.4 compatibility will be
>meaningless on the server side at that point.
>
>
Moreover one has to wonder how many pre-Java-5 environments are going to
bother deploying new versions of log4j...
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j and Java 5
Posted by Yoav Shapira <yo...@computer.org>.
Hi,
Doug Lea's concurrent library is a good piece of software. We used it
at my old workplace for a couple of years in heavy apps, never a
problem. And now it's part of JSE 5 so future migration will be easy.
One could also imagine a simple class that detects if running on JSE5
and later and then uses java.util.concurrent, or else uses Doug Lea's
library.
Requiring JSE5 for log4j is probably not a good idea: one of log4j's
main advantages over JDK 1.4 logging is its ability to run on older
JVMs.
That said, JSE5 is not only being rapidly adopted (for example, on the
Tomcat mailing lists, we've seen far more JSE5 than JDK 1.4 queries
not just recently, but for almost two years now), but it will be
required for JEE5 containers. So, for example, Tomcat 6, Jetty 7,
Geronimo 1.1, Weblogic 10, etc will all require JEE5 or higher as
their JVM -- the JDK 1.1, 1.2, 1.3, 1.4 compatibility will be
meaningless on the server side at that point.
I wonder what percentage of log4j users are client side versus server
side. One has to assume 50-50, but who knows ;)
Yoav
On 12/2/05, Endre Stølsvik <En...@stolsvik.com> wrote:
> On Thu, 1 Dec 2005, Jess Holle wrote:
>
> | Has anyone tried replacing the synchronization in log4j with Java 5 locks to
> | and done any benchmarks?
> |
> | I'm curious as I think it would be interesting to have a lock factory which
> | produces something like the existing locks for pre-Java-5 JVMs and Java 5
> | locks in Java 5.
> |
> | We purely use and require Java 5 and higher for all new development at this
> | point, which may make us unusual, but that's where we're at. I understand the
> | need to support earlier JVMs, but am interested in squeezing the best possible
> | performance and scalability out under Java 5.
>
> My opinion: Server-side programs and in particular libraries don't always
> have the opportunity to _decide_ the infrastructure, one important pice of
> which is the JRE version.
>
> What about Doug Lea's "concurrency.jar", which basically _is_ the JSR 166?
> This works with 1.2+, and most also "should" work with 1.1 (1.2 is
> "collections")
>
> http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
>
> Other elements of concurrency.jar worth examining for the ones of you that
> are heavily into the innards of log4j, are possibly:
> ConcurrentHashMap
> ConcurrentReaderHashMap
> ReadWriteLock
> and obviously
> Sync and Mutex possibly along with CondVar
>
> Regards,
> Endre.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j and Java 5
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Thu, 1 Dec 2005, Jess Holle wrote:
| Has anyone tried replacing the synchronization in log4j with Java 5 locks to
| and done any benchmarks?
|
| I'm curious as I think it would be interesting to have a lock factory which
| produces something like the existing locks for pre-Java-5 JVMs and Java 5
| locks in Java 5.
|
| We purely use and require Java 5 and higher for all new development at this
| point, which may make us unusual, but that's where we're at. I understand the
| need to support earlier JVMs, but am interested in squeezing the best possible
| performance and scalability out under Java 5.
My opinion: Server-side programs and in particular libraries don't always
have the opportunity to _decide_ the infrastructure, one important pice of
which is the JRE version.
What about Doug Lea's "concurrency.jar", which basically _is_ the JSR 166?
This works with 1.2+, and most also "should" work with 1.1 (1.2 is
"collections")
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
Other elements of concurrency.jar worth examining for the ones of you that
are heavily into the innards of log4j, are possibly:
ConcurrentHashMap
ConcurrentReaderHashMap
ReadWriteLock
and obviously
Sync and Mutex possibly along with CondVar
Regards,
Endre.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org