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