logging theshold

[Martin Cavanagh]

Hi Log4jdbc users.

I successfully used log4jdbc to find some performance problems today. Its really awesome.

Since I'm a little overwhelmed with the amount of output in my productive system (I know, I know, I shouldn't use it there)....I decided it would be great to utilise the threshold feature to limit my SQL queries to only the ones that run 500ms or longer. Fantastic - log4jdbc has that feature ready to go.

My problem is this, I have jobs that run every night and import and update hunreds of thousands of records everynight. Those queries are allowed to run longer than 500ms. I'd like to somehow NOT log those database scripts - depending on the calling java code (perhaps as a regex expression). For those statements its quite okay if they take much longer than 500ms. The best solution might be to combine these with another threshold, which logs these if they are longer than expected. Is there any chance of something like this exists already? and if not, how hard would it be to extend log4jdbc to include this?

Thanks

Martin Cavanagh

[Arthur Blake]

Thank you for your kind statements.  There is currently no direct functionality for what you want to do, but there is similar functionality that you might be able to adapt with a little bit of coding.  When setting the logging level to debug, you can set a property,  log4jdbc.debug.stack.prefix in order to hone in on your application code in the debugging output.  This is useful for just finding where the SQL is emanating from.  Maybe combining some of that logic with some kind of regex filter that is set in another new parameter would get you what you want.

I am extremely busy with other projects right now, but if you are handy with java and want to crack open the log4jdbc code and see if you can get something working for your needs with that knowledge, I think things are rather well laid out and it wouldn't be too hard to modify it in that way. 

I'm glad you realize that you shouldn't be running this in production (at least not for too long with high volume) as log4jdbc was not intended to run in production and there are certain parts of it that are rather slow (such as the debug stack trace logic I just mentioned) and may have negative consequences on your production systems.

I did start work on a new project, "a log4jdbc, the next generation" so to speak that is designed specifically for running on production level systems, but that is nowhere near done (and will not be any time soon.)

Good Luck, and feel free to ask more questions here-- although I may not always be quick to respond.