JMX for OOM warning : Helpful but Useful?

Javaspecialist put up a good article on using java management API to introspect the JVM memory pool. A listener can be registered to the management bean which is a call back for the bean if the memory usage is exceeding the threshold value. Threshold value can be set by using MemoryPoolMxBean.setUsageThreshod(long) method.

This is all great, I can have some auto script warn the primary engineer or operations about memory related issue in advance. But what does it buy us apart from the advance notice. In my experience I have seen following actions for a OOM in live server

Script action:
A) Setup a back ground script on the server which looks for OOM exception on server log.
B) If the script finds an OOM exception , a restart is performed.
C) Script also alerts the production control for further action.

Engineer action:
D) Doh! I got a pager, damn why is it that pager rings on darn weekend. Ahh OOM, wish I had not replaced the pager battery.
E) Hum... Let me look at for some temporarily solution so I can buy some time. How about heap size increase or may be scale the server.
F) Back to office, setup profiler tool and figure out if there is a memory leak.
G) Send out an email with finding and resolution.

So having said this, I would be interested to know if you see any additional benefit from the management bean for OOM related issues? Also if you have some other ways to deal with live production OOM issues let me know.

Cheers
Anand

Bookmark this: JDiff

So many times a blog is nothing but reference to others, but that is what blog is all about. I do feel that we should not always have to "write our own innovative blog", most of the time somebody has already thought about what you are writing but your way to express is what matters here and we ( blog readers) look forward to reading them.

I think the basic rule is : if you are not commenting on a blog or adding additional information, just for promotional purpose give the reference. Also copy pasting a blog is not a taboo, your blog is not just blog readers reference but your reference as well. So if you like a blog very much and don't want to loose it because that blogger might shut down the blog site , go do the copy-paste.

Since I talked about refrenences I happen to see a good sourceforge utility which provides differences in Java API. Wish I knew about it before, here is the Reference

Virtual spy driver for JDBC

IronGrid provides an easy to use virtual spy driver for JDBC which can be used to gather performance related data for all your SQL queries. I have benefited it from it so give it a try if you are not using something similar.

The driver is called p6spy which wraps the JDDC driver and traps all the request coming and going through it. Thus it has the flexibility in keeping frequency/responsiveness of your SQL queries. Apart from trapping the data this driver also listen to port( configurable) which can be used to connect from a client ( provided by IronGrid) to read the data.

Three things rocks most

1) You don't have to make a single line of code change on your app server. Everything is configured.
2) You can see the binding variable data on your prepared statement, which I believe is wonderful as I miss it a lot with straight JDBC logging.
3) Provides a client which can get all these data and present it in a nice way, can also generate reports.

Setup is quite straight forward , basically put the jar file in classpath and configure the spy.properties so it knows which driver it has to wrap.It supports most of the popular JDBC driver, and the product is free of cost!!!

JDBC4.0 API feature sets

Some attachments from the feature sets of JDK5 like generic,MetaDeta and JDO and more..

1) Simpler access( factory) to Datasource,Get the connection of data source by parameters( host,port etc) rather than the JDBC URL.
2) Some enhancements over that state of Connection
3) Complaint to SQL 2003 : This brings
3.1 Associate SQL queries with object structure, inline with ORM ( object relational mapping)
3.2 SQL/XML support for XML datatypes.
4)Easy migration from JDBC rowset model( disconnected datasource access) via XML stand-point.

To me best they have to offer us is point-2 ( enhancement on state of connection). Now conncetion object can provide us a way check the validity of connection rather than just isClosed().

Mock SMTP server for Java emails

Ever got stuck with IT guys for having setup the SMTP server so that you can start testing your java application which has to deal with the emails. Now no more.... I happened to see a good tool which will mock the SMTP server. Its called Dumpster. It understands the SMTP protocol and does everything until the email has to be delivered. Email is cached so if you see it in cache consider that it should have been recieved by the user.


Here is the link:

Mock SMTP server

UncaughtExceptionHandler in Java5

Java5 provides a better way to handle the uncaught exception thrown by abnormal thread termination. Now the application can define its own handler which will be called by JVM if the thread is terminated and exception is not caught. The order of sequence is as follows

1) JVM checks if the Thread is handling the exception if not
2) It delegates the responsibility to handle the exception to the ThreadGroup object,if ThreadGroup does not handle the exception, then
3) JVM checks to see if there is Handler( object implementing Thread.UncaughtExceptionHandler) set for the Thread, if so ,JVM delegates the exception to the handler to handle. If no handler is defined for the Thread, then
4) JVM asks the ThreadGroup to use the default handler , if there isn't one, then JVM uses the pre 1.5 way of using the ThreadGroup to deal with handling the exception.

Advantages of defining a default handler:

1) Provides one layer of granularity of controlling the exception
2) Each Thread can have its own default exception handler.

How to build maintainable systems: Simple design

Wonderful post by tirsen on codehaus blog, I very much agree with him.

I'm not saying that simple designs by some divine judgement are better designs (I do believe so, I just don't want to start that particular debate again). There are other much larger problems with complicated designs when it comes to implementing maintainable systems: complicated designs usually become poorly understood and therefor poorly implemented.

I've seen this many times in the field: Some hot-shot architect works for an intense period early in a projects lifecycle and produces some really hot-shot, ultra-cool, super-slick design that solves everything that the system would ever be conceived to do and then some. Job done, the architect leaves for his next hot-shot assignment (he holds himself too high for such profane tasks as, bah, implementation).

Left on the project are a bunch of more junior people who are up to the task of actually delivering the system. If they ever understood the design in the first place they are certainly not understanding it good enough to be able to maintain it when exposed to realities such as time-pressure, performance problems, inconsistent requirements and so forth. The design starts to break down and technical debt accumulates. The biggest problem now is that not only has the design broken down, they are also dragging around a massive framework hampering their every step.

I have been to places that had frameworks of hundreds and hundreds of classes that when it came down to it did the equivalent functionality of about two mid-sized classes work. I kid you not.

Some warning signs to look out for:

"We're building a generic framework so it will take a little longer to deliver the first project. But then we will be able to reuse all this stuff so we'll save time in the long run." (Building reusable software is many, many times more difficult, expensive and time-consuming than one-off software. Is there really a business case for a reusable framework?)

"Let's build it so that all this functionality can be accessible from any possible client." (Technologies like web services or CORBA has a huge up-front cost in terms of complexity. It's better to build the remote interfaces when the client actually exists.)

"Make the customer disappointed the first time, because they will be more than happy the next time." (Are you sure you will get a next time?)

"We want to use a rules engine so that the business can easily extend the system in the future." (Even a rules engine requires programmers to write the rules.)

"It might seem a little complicated for this simple project, but if we stick to a standard technology we can be sure to find developers that can maintain the system in the future." (Nobody can maintain an unmaintainable system, standard or no standard.)

Java Prevalence, is it ridiculously that simple?

There is a talk in the town, its called "Prevayler"( http://www.prevayler.org/wiki.jsp) . The idea is towards getting rid of Relational databases( Making Larry Ellison run for money) and persisting the data in-memory, yes all the data in memory. Now the claim is that its ~9000 times faster than using relational databases. Prevalyer has data objects ready to be used , meaning, you don't have to perform the object creation every time a data is being retrieved thus it saves on the costly object creation time. These objects are supposed to be cached in the same physical machine so you don't have deal with network latency and cost associated with such for database driven applications.

Folks behind this idea considers it ridiculously simple also its strange that they use the word prevalence which literally mean "Generally accepted". It is really that simple or can it be generally accepted.

I don't want to repeat what's in Prevalyer website. Prevalence folks have already figured how they can deal with system crash, backups/restore etc. What I am curious is how they are benchmarking Prevalance with relational database?

Some catchy points about Prevalance which are so debatable -->

** Rollback is needless according to prevalence. Wait a second, what about the A part solved by RDBMS in ACID, the Atomicity. I was looking for how prevalence answer my question and found that suggestion is pretty lame. Do a try and catch on your business object and have the catch remove the object graph associated so far before the exception happened. Well for first its clear that prevalence does not provide ACID and second I am not sure how you can revert from the catch block.

** Two-Phased commit is unnecessary. Well I just leave this comment to as is ...

** No SQL use OQL( Object query Language ).

In short I believe the attempt so far can be useful in using prevalence as good object caching architecture which guarantee cache recovery. But then do I need a cache database for it......