You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Vic <vi...@friendvu.com> on 2005/02/16 04:52:05 UTC
jcl blog post
http://www.osnews.com/files/WinXP-security-guide.pdf
.V
--
Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
FWIW
this is a well known issue with JCL and there's no way to cure it on 1.2
JVMs (which was the target for JCL). (thanks to brian) for a few months
now, HEAD has had compatible code which allows memory reclamation on
more modern JVMs (with weak references). if a few more folks were
prepared to test the release candidate, this code might even get a
release...
it's only a practical issue in containers which have JCL placed into a
classloader high in the tree and then hot deploy contained applications
without calling release. it is also documented in the javadocs (which
should help to explain why it took so long for users to discover this
limitation.)
at least ceki puts time and effort into researching his critiques...
- robert
On Wed, 2005-02-16 at 04:50, Vic wrote:
> oops :-[
> Wrong link, this is it:
> http://www.szegedi.org/articles/memleak.html
>
> It talks about Commons logging, since i'ts open season.
> .V
>
> <http://www.boardVU.com>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by Vic <vi...@friendvu.com>.
Once resin 2.x and once resin 3.x. And I always included all jars in
WEB-INF (except JDBC driver)
I just started using tc5.5.x for production. I allways do stress test
to shake out. (here I might use ugli, BUT.... iBatis jar does not even
run w/o JCL, else I would)
.V
Ceki Gülcü wrote:
>
>
>
> Was your deployment combination different from the above?
--
Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by Ceki Gülcü <ce...@qos.ch>.
Vic,
The defects can be reproduced easily.
Assuming you deployed your application on Tomcat, the combination known to
work safely is:
1) Leave the file TOMCAT_HOME/bin/commons-logging-api.jar as is.
2) Place the files commons-logging.jar and log4j.jar in the directory
TOMCAT_HOME/commons/lib/.
3) Do not include any other copies of commons-logging.jar and log4j.jar in
your web-applications' WEB-INF/lib/ directory.
4) Do not set the org.apache.commons.logging.LogFactory property.
Was your deployment combination different from the above?
At 02:54 PM 2/18/2005, Vic wrote:
>I used to use both together. For what ever reason, I have stress tested
>and put in production several systems, one with 10,000 concurrent users,
>one w/ 40,000 concurrent users... and everything seems to be working. I
>was not aware of any bugs.
>
>Now .... I use WebStart so likely at least a part will be JDK logging.
>.V
>
>Ceki Gülcü wrote:
>
>> a problem with JCL, a totally defective piece of
>>software, which makes life very difficult, if not impossible, for
>>log4j users.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by Vic <vi...@friendvu.com>.
I used to use both together. For what ever reason, I have stress tested
and put in production several systems, one with 10,000 concurrent users,
one w/ 40,000 concurrent users... and everything seems to be working. I
was not aware of any bugs.
Now .... I use WebStart so likely at least a part will be JDK logging.
.V
Ceki Gülcü wrote:
> a problem with JCL, a totally defective piece of
> software, which makes life very difficult, if not impossible, for
> log4j users.
--
Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by Ceki Gülcü <ce...@qos.ch>.
Yes, I do have a problem with JCL, a totally defective piece of
software, which makes life very difficult, if not impossible, for
log4j users. The way Craig systematically dismisses legitimate
criticism against the software he authored is also quite disturbing.
If you read his emails, JCL has only minor problems in "corner"
cases. Otherwise, people would be complaining wouldn't they? But for
the vast majority of users, the priority is solving the problem not
complaining in some mailing list. It also happens that the fastest way
of solving JCL related problems is abandoning the use of log4j in
favor of java.util.logging.
When maybe 1 user out of 10'000 users does complain, the complaint is
quickly ascribed to inability to read instructions, i.e. incompetence
by the user in question.
The current situation whereby a piece of software distributed by the
Apache Software Foundation intentionally or unintentionally
*prohibits* the use of another piece of software also distributed by
the Apache Software Foundation cannot continue for much longer.
At 04:05 PM 2/17/2005, you wrote:
>You got issues.
>.V
>
>
>Ceki Gülcü wrote:
>
>>, it looks like you
>>are still in stage one, denial, with stage 5, acceptance, seemingly
>>out of reach.
>
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by Vic <vi...@friendvu.com>.
You got issues.
.V
Ceki Gülcü wrote:
> , it looks like you
> are still in stage one, denial, with stage 5, acceptance, seemingly
> out of reach.
>
--
Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by Ceki Gülcü <ce...@qos.ch>.
At 06:02 AM 2/16/2005, Craig McClanahan wrote:
>There's lots of ways to shoot yourself in the foot the same way ...
>you don't need JCL to do that ... pretty much any implementation of
>the factory design pattern should be looked at with suspicion.
JCL brings very new and original ways of shooting yourself in the
foot. With JCL you can shoot yourself in the foot while aiming at the
sky. Thanks to JCL you can be hit by lightning in the middle of the
desert when it's not raining. If your computing life is too dull and
trouble is what you are looking for, then JCL is certainly the way to
go.
Craig, with respect to the severity of JCL's bugs, it looks like you
are still in stage one, denial, with stage 5, acceptance, seemingly
out of reach.
If I did not know any better, I'd say that JCL was voluntarily
designed to kill logging APIs other than java.util.logging but Craig
wouldn't do that to a fellow Apache project, would he?
>Craig
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by Shey Rab Pawo <pa...@gmail.com>.
Presently I am having a horrible problem with font resources not being
deallocated. I am using Tiger, Tomcat 5.0 and Struts 1.2.6 and every
image I create with a Font object involved leaves an unwelcome .tmp
file in the [TOMCAT_HOME]/temp directory. Someone else solved this
problem by going to Tiger, but that has not worked for me. Any
information on this?
On Thu, 17 Feb 2005 13:29:14 -0800 (PST), David Graham
<gr...@yahoo.com> wrote:
>
> --- Vic <vi...@friendvu.com> wrote:
>
> > Craig McClanahan wrote:
> >
> > > pay attention to
> > >the Javadocs for CatalogFactory.clear() ;-)
> > >
> > >
> > >
> > :-D :-D
> >
> > Sort of..."dealocate"?
> > SWT too, you to "dealocate" fonts you use.
>
> While that's technically true, I have been using SWT for over a year now
> and have never needed to dispose of any resources manually. SWT provides
> Image and Font registries that handle that for you. Also, all child
> controls are disposed when their parent is disposed.
>
> It's much nicer than some people would like you to believe.
>
> David
>
> >
> > I grined for a day. 10 years later, we are full circle.
> >
> > .V
> >
> > --
> > Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
> __________________________________
> Do you Yahoo!?
> Meet the all-new My Yahoo! - Try it today!
> http://my.yahoo.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
The radiance of all the stars does not equal a sixteenth part of the
moon's radiance, likewise, good deeds giving us merit, all these do
not equal a sixteenth part of the merit of loving-kindness..
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by Martin van den Bemt <ml...@mvdb.net>.
>>
>>:-D :-D
>>
>>Sort of..."dealocate"?
>>SWT too, you to "dealocate" fonts you use.
>
>
> While that's technically true, I have been using SWT for over a year now
> and have never needed to dispose of any resources manually. SWT provides
> Image and Font registries that handle that for you. Also, all child
> controls are disposed when their parent is disposed.
>
> It's much nicer than some people would like you to believe.
>
In Swing you need to dispose stuff too, else you'll end up with a lot of
memory leaks (which most people are unaware off..). That's worse than
knowing up front that you need to dispose stuff you create in my view..
Mvgr,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by David Graham <gr...@yahoo.com>.
--- Vic <vi...@friendvu.com> wrote:
> Craig McClanahan wrote:
>
> > pay attention to
> >the Javadocs for CatalogFactory.clear() ;-)
> >
> >
> >
> :-D :-D
>
> Sort of..."dealocate"?
> SWT too, you to "dealocate" fonts you use.
While that's technically true, I have been using SWT for over a year now
and have never needed to dispose of any resources manually. SWT provides
Image and Font registries that handle that for you. Also, all child
controls are disposed when their parent is disposed.
It's much nicer than some people would like you to believe.
David
>
> I grined for a day. 10 years later, we are full circle.
>
> .V
>
> --
> Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by Vic <vi...@friendvu.com>.
Craig McClanahan wrote:
> pay attention to
>the Javadocs for CatalogFactory.clear() ;-)
>
>
>
:-D :-D
Sort of..."dealocate"?
SWT too, you to "dealocate" fonts you use.
I grined for a day. 10 years later, we are full circle.
.V
--
Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by Remy Maucherat <re...@gmail.com>.
On Tue, 15 Feb 2005 21:02:28 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Tue, 15 Feb 2005 22:50:51 -0600, Vic <vi...@friendvu.com> wrote:
> > oops :-[
> > Wrong link, this is it:
> > http://www.szegedi.org/articles/memleak.html
> >
> > It talks about Commons logging, since i'ts open season.
> > .V
>
> There's lots of ways to shoot yourself in the foot the same way ...
> you don't need JCL to do that ... pretty much any implementation of
> the factory design pattern should be looked at with suspicion.
>
> By the way ... if you use [chain] you should *really* pay attention to
> the Javadocs for CatalogFactory.clear() ;-)
I like this one too, which is very similar (and of course,
undocumented - the javadocs make you think the method which has to be
called to resolved the leak is useless; the issue is also very hard to
diagnose, as for some reason profilers will not "see" references kept
by this cache):
http://issues.apache.org/bugzilla/show_bug.cgi?id=26135#c6
If I was still working in Santa Clara, the J2SE folks would have heard
I wasn't happy about their "cool" feature ;)
--
xxxxxxxxxxxxxxxxxxxxxxxxx
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
xxxxxxxxxxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by "Kevin A. Burton" <bu...@newsmonster.org>.
Shey Rab Pawo wrote:
>>Anyway... I called my newborn connection pool BDCP (basic database
>>connection pool).
>>
>>Its about 1/5 the size of DBCP and a LOT easier to maintain.
>>
>>
>
>I built my own connection pool for similar but less informed reasons.
>I found DBCP to be simply unworkable for some reason. I may have been
>at fault, but I normally do not have that much trouble with anything.
>I would be very interested in seeing your BDCP, if you are making that
>public.
>
>
>
I was thinking about just putting it in the sandbox. I wanted to get my
benchmark code public first though...
Kevin
--
Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an
invite! Also see irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
If you're interested in RSS, Weblogs, Social Networking, etc... then you
should work for Rojo! If you recommend someone and we hire them you'll
get a free iPod!
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
Re: jcl blog post
Posted by Shey Rab Pawo <pa...@gmail.com>.
> Anyway... I called my newborn connection pool BDCP (basic database
> connection pool).
>
> Its about 1/5 the size of DBCP and a LOT easier to maintain.
I built my own connection pool for similar but less informed reasons.
I found DBCP to be simply unworkable for some reason. I may have been
at fault, but I normally do not have that much trouble with anything.
I would be very interested in seeing your BDCP, if you are making that
public.
--
The radiance of all the stars does not equal a sixteenth part of the
moon's radiance, likewise, good deeds giving us merit, all these do
not equal a sixteenth part of the merit of loving-kindness..
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Wed, 2005-02-16 at 06:57, Kevin A. Burton wrote:
> Craig McClanahan wrote:
>
> >On Tue, 15 Feb 2005 22:50:51 -0600, Vic <vi...@friendvu.com> wrote:
> >
> >
> >>oops :-[
> >>Wrong link, this is it:
> >>http://www.szegedi.org/articles/memleak.html
> >>
> >>It talks about Commons logging, since i'ts open season.
> >>.V
> >>
> >>
> >
> >There's lots of ways to shoot yourself in the foot the same way ...
> >you don't need JCL to do that ... pretty much any implementation of
> >the factory design pattern should be looked at with suspicion.
> >
> >By the way ... if you use [chain] you should *really* pay attention to
> >the Javadocs for CatalogFactory.clear() ;-)
> >
> >
> You know I have a similar little story about Commons DBCP.
>
> Its evil.. pure evil! ;)
>
> I actually rewrote it from scratch because I needed a good connection
> pool implementation and DBCP just wasn't cutting it but it was 85% there.
>
> So one weekend I gutted the core and wrote my own pool implementation
> and increased performance significantly.
>
> The key part for me was that for SOME reason in my highly multithreaded
> app it would bleed connections. After about 48 hours our app wouldn't
> have any more connections and all my threads would sit there sleeping
> waiting for connections that would never come.
>
> Anyway... I called my newborn connection pool BDCP (basic database
> connection pool).
>
> Its about 1/5 the size of DBCP and a LOT easier to maintain.
>
> Anyway... I was considering OSSing it here in the future but didn't know
> how to approach it with commons-dbcp folks...
http://incubator.apache.org/learn/rules-for-revolutionaries.html
a lot of the stuff which was created in the early days of the commons is
pretty mature: either it's been taken as far as it can, or as far as the
limitations of original design (and so backwards compatibility) or by
conception (the limitations set by the original creators). there is a
place for well maintained, relatively well tested and well used
libraries. there is also a place for new libraries offering potential
benefits but which aren't as well tested in production.
however, it's also important to be positive about the benefits offered
by the new (as opposed to simply being negative about the old). it's not
unusual for better designs to emerge by discussing different approaches
to the same problem.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by "Kevin A. Burton" <bu...@newsmonster.org>.
Craig McClanahan wrote:
>On Tue, 15 Feb 2005 22:50:51 -0600, Vic <vi...@friendvu.com> wrote:
>
>
>>oops :-[
>>Wrong link, this is it:
>>http://www.szegedi.org/articles/memleak.html
>>
>>It talks about Commons logging, since i'ts open season.
>>.V
>>
>>
>
>There's lots of ways to shoot yourself in the foot the same way ...
>you don't need JCL to do that ... pretty much any implementation of
>the factory design pattern should be looked at with suspicion.
>
>By the way ... if you use [chain] you should *really* pay attention to
>the Javadocs for CatalogFactory.clear() ;-)
>
>
You know I have a similar little story about Commons DBCP.
Its evil.. pure evil! ;)
I actually rewrote it from scratch because I needed a good connection
pool implementation and DBCP just wasn't cutting it but it was 85% there.
So one weekend I gutted the core and wrote my own pool implementation
and increased performance significantly.
The key part for me was that for SOME reason in my highly multithreaded
app it would bleed connections. After about 48 hours our app wouldn't
have any more connections and all my threads would sit there sleeping
waiting for connections that would never come.
Anyway... I called my newborn connection pool BDCP (basic database
connection pool).
Its about 1/5 the size of DBCP and a LOT easier to maintain.
Anyway... I was considering OSSing it here in the future but didn't know
how to approach it with commons-dbcp folks...
Kevin
--
Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an
invite! Also see irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
If you're interested in RSS, Weblogs, Social Networking, etc... then you
should work for Rojo! If you recommend someone and we hire them you'll
get a free iPod!
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
Re: jcl blog post
Posted by Vic <vi...@friendvu.com>.
Yeah, thanks. I don't have many commands, they just get called over and
over.
It just make sense that statics stay.
.V
Craig McClanahan wrote:
>
>By the way ... if you use [chain] you should *really* pay attention to
>the Javadocs for CatalogFactory.clear() ;-)
>
>Craig
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by Craig McClanahan <cr...@gmail.com>.
On Tue, 15 Feb 2005 22:50:51 -0600, Vic <vi...@friendvu.com> wrote:
> oops :-[
> Wrong link, this is it:
> http://www.szegedi.org/articles/memleak.html
>
> It talks about Commons logging, since i'ts open season.
> .V
There's lots of ways to shoot yourself in the foot the same way ...
you don't need JCL to do that ... pretty much any implementation of
the factory design pattern should be looked at with suspicion.
By the way ... if you use [chain] you should *really* pay attention to
the Javadocs for CatalogFactory.clear() ;-)
Craig
> <http://www.boardVU.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: jcl blog post
Posted by Vic <vi...@friendvu.com>.
oops :-[
Wrong link, this is it:
http://www.szegedi.org/articles/memleak.html
It talks about Commons logging, since i'ts open season.
.V
<http://www.boardVU.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org