|
|
|
|
Back to newsletter 097 contents
I found myself going back to (www.p6spy.com) p6spy again recently - as I have with almost every project and consulting engagement I've been involved in for the last 7 years (I can't recall exactly how long, but I obviously knew about it in 2001 when I wrote this article about JDBC monitoring). P6spy has been hugely useful to me over the years, and I was wondering why it seems to have become a dead project? Not that it needs much work, it works very well as is, but even the very few known and obvious bugs haven't been fixed since 2003.
Does anyone know? I do know that when Irongrid folded, the main source of support for p6spy disappeared. For those of you unaware, Irongrid was an early company selling open source software services, and their software (ironeye and more) was built as a set of GUI and analysis tools on top of p6spy, that helped you analyse JDBC communications. The software itself was quite nice, but the business model (a for-profit company based on fairly niche open source software) was probably too early for success.
Regardless, the last downloadable version of p6spy is from 2003, and it has bugs. Yes, I know, I should fix them and check in the fixes, it is still open source after all. But apart from that, I'm curious why there has been no movement on this project in five years, and whether people are using other solutions? Oddly, I find that any project I go to either uses an equivalent commercial product, or their first question to me is "how can we profile JDBC communications"? (Actually, usually both of those). So it's not like there is a lack of need for p6spy or equivalent. I'd welcome an update from any reader - what are you using to profile JDBC, and why are you using that?
Now on with this month's newsletter. We have our usual lists of Java performance tools, news, and articles. Though this month's listing of news items uses URLs that are a bit old - as an end of year clearout, we went through all the news items that were dumped on the pile over the year, but which didn't make it into earlier newsletters because of lack of time, and we've included those items that really should have got into one of the newsletters. Sorry for the delayed news, but the info is worth knowing, so we decided it was worth including.
Other than that, sadly for you Javva The Hutt fans, he's on holiday, but at fasterj we have a new cartoon Detecting deadlocks; and, of course, we have extracted tips from all of this month's referenced articles.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 097 contents
