First, you are referring to Log4j 1.x. Most of our work is currently focused
on Log4j 2. That said, you would have the same issue with Log4j 2, Logback or
even java.util.logging.
What possible reason could you have for creating a logger per subscriber? The
key to us being able to provide a solution is to know what you are attempting
to accomplish by doing that. You cannot possibly configure 10 million loggers
so it can't possibly have anything to do with that. If it is to have some
mechanism to identify the subscriber than there are much better ways to do
that.
I would suggest reading through the Log4j 2 manual at
http://logging.apache.org/log4j/2.x/manual/index.html and seeing if the
facilities it has provide a solution.
Ralph
On Aug 26, 2013, at 1:32 PM, Deon van der Merwe wrote:
> Hi,
>
> For every new category created a new entry is added into
> org.apache.log4j.Hierarchy.ht. And at the same time also for any possible
> parent category of that new entry.
>
> This cache is fine when you have a fairly fixed number possible categories.
> That cache will grow to some size and remain that size.
>
> In our application we have several static categories but then also categories
> which consists of some subscriber identity. Possible range here is in the
> order of tens of millions. Most of these subscriber identity categories live
> for a fairly short time, let's say less than 10 minutes. Below is a sample
> output from jstat showing the number of Logger objects going over 11M. At
> that point the GC starts to complain and the JVM is starting to suffer.
>
> Now, org.apache.log4j.Hierarchy has a "clear" method which will just clean
> the ht lookup completely. Using that clear feels a bit harsh/extreme,
> especially considering that we still have categories that do live a very long
> time.
>
> So, the question is if using "clear" is good practice or not? If it is good,
> then fine. If not: what is good practice for keeping this ht lookup size
> down to more practical levels (looking at current/live traffic etc)?
>
>
>
> num #instances #bytes class name
> --
> 28: 418071672280 org.apache.log4j.Logger
> 20: 880863523440 org.apache.log4j.Logger
> 15:1138354553400 org.apache.log4j.Logger
> 18:1332675330680 org.apache.log4j.Logger
> 16:1523796095160 org.apache.log4j.Logger
> 15:1735596942360 org.apache.log4j.Logger
> 11:2104808419200 org.apache.log4j.Logger
> 11:316526 12661040 org.apache.log4j.Logger
> 10:672608 26904320 org.apache.log4j.Logger
> 2:892928 35717120 org.apache.log4j.Logger
> ...
> ...
> ...
> 2: 11295227 451809080 org.apache.log4j.Logger
> 2: 11301788 452071520 org.apache.log4j.Logger
> 2: 11317688 452707520 org.apache.log4j.Logger
> 2: 11352595 454103800 org.apache.log4j.Logger
> 2: 11389363 455574520 org.apache.log4j.Logger
> 2: 11428866 457154640 org.apache.log4j.Logger
> 2: 11470739 458829560 org.apache.log4j.Logger
> 2: 11514552 460582080 org.apache.log4j.Logger
> 2: 11556256 462250240 org.apache.log4j.Logger
>
>
>
> --
> __Deon___
> TruTeq Wireless (Pty) Ltd. Tel: +27 12 667 1530
> http://www.truteq.co.za Fax: +27 12 667 1531
> Timezone: SAST GMT+2
> Copyright&Legal: http://truteq.co.za/legal_notice.pdf
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
