Hi, found p6spy while looking for a tool to help tune some CMP performance issues. Great work! I like it a lot and am recommending it to other developers where I work. However, there might be a little room in some areas. Here's my feedback:
1. Make the log file output string format more configurable. For example, I've got p6spy set to use our existing log4j appender, which is great. But I already get the log entry timestamp from log4j, I don't need it again from p6spy. I'd suggest emulating log4j's PatternLayout string.
2. ResultSets are not logged when enabled.
3. I'd suggest using a more efficient default logger; I almost abandoned the tool because the p6spy's default configuration is FileLogger with flush=true. Once I reconfigured to use log4j the impact dropped to a minor issue.
4. Enabling StackTrace results in NullPointerExceptions, at least on in my environment.
Other than that, it looks great and has become a valuable tool in my toolkit. Thanks. I'll try to contribute fixes to the above issues if/when I get responses to my feedback.
Another suggestion: Since I work in a connection-pooled environment, adding a connection identifier would be nice.
I think these are all fantastic suggestions, I have added them all into Bugzilla. I think we plan to address all of them in the next couple of weeks except for the connection suggestion. That being said, I really I think this is really a great suggestion and addition to the product - I really like the idea of (1) logging connections in general and (2) including a connection identifier, but right now we have our plate full ... so I might take you up on your offer. If you are interested and would like to write the code to support this, I would be more than happy to integrate your contribution into the codebase. Let me know what you think - you can reach me at firstname.lastname@example.org.
One other question I had - I very much agree with your comment on the logging - do you have a good suggestion on how to deal with this? I turned flush=true as the default just because we had several people complain about not seeing information "real time" in their application (a flush had not occured) but I think balancing that with your concern is very important. Also, I happen to be a big fan of log4j, but wanted to avoid requiring log4j to be in the deployment environment ... so I am definitely open to ideas on that front.
Thanks for the kind words Jeff,
Re: Your question on log file flushing, this seems like the classical performance vs. robustness problem - It's difficult to be both fast and robust at the same time.
My issue wasn't that the software was slow, but that it was slow in it's default configuration and this negatively impacted my impression of the product. It's a marketing thing - I wonder how many developers silently tried and abandoned the product simply because their expectations wern't met and they didn't take the time to play with the settings? First impressions are important.
So I'd probably take the easy way out by setting the flush default back to false and better document the buffering effect the filesystem can have on the output.
The schemes of varying complexity that come to mind that force the buffer to flush (low-priority flush thread, every 'Nth' log message flush, etc) aren't going to flush the log every message like some want, so I don't see any other alternatives.
I'll email you directly on the rest.
another thought is to log the output to the console as the default.