On 24.10.2012 20:46, Becker, Thomas wrote:
Thanks, I'll look into changing the configuration to use elements.
> I was not aware of the FINALIZE_SESSION marker, though I don't think
> it would work for our use case. My RFE was originally to just make
> the appender timeout configurable. But then I thought about it more
> and decided the real problem was that there is no way to cap the
> number of sub-appenders (and the scarce resources they consume, like
> FDs) that can be spun up in response to a burst of activity. In our
> case, we expose a job engine to clients and use SiftingAppender to
> direct each job to its own log. But when we get a flood of new job
> submissions, we ran out of FDs which cripples the system in all sorts
> of ways that should not be affected by logging. But now we can cap
> the number of appenders we want to allow, and clients don't need to
> know to pass a marker stating they're done with the logger. So I
> guess I'm saying that although the marker is nice, the maxAppenders
> setting is more like a safety valve to keep Bad Things from happening
Capping the max number of sub-appender sound like what *not* to do in
your scenario. For example, if the cap is 100 and 101 requests are
received in a short amount of time, then you will be prematurely
opening and closing sub-appenders in the scenario you describe.
Reconfiguring an sub-appender is not exactly cheap.
I reiterate my question. Can you identify an end-of-session point in
your code after which resources can be released?
--
Ceki
65% of statistics are made up on the spot
_______________________________________________
logback-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
