[Reminder for myself] Performance Monitoring

Determine the points where requests are waiting or slow

If system is busy, deny request at the earliest entry point (e.g. if database is busy then stop accepting requests at the web server)

If under load stop accepting requests and

• process pending requests or
• drop them all or
• restart application 

If adjusting system make sure you're not just moving the load to some other component (e.g from CPU->HDD)

Things to check for

Java:

• Pools size
• Heap utilization
• Garbe collection
• Cache hit ratio
• Messaging systems

Communication:

• Network I/O (bytes r/w, throughput)

OS:

• Disk I/O
• CPU usage
• Memory usage
• Threads usage

Notes on JUnit @After Annotation

Notes on JUnit @After Annotation:

• All methods marked with @After are executed
• The method named tearDown executes even if it's not marked as @After
• @After annotation is not inheritable so you need to add @After if you override the annotated method
• Remember to call super.tearDown if you override tearDown in you class
• For class hierarchies it is best to use different clean-up methods with different names, marked with @After, so they're all called automatically and you won't accidentally override them.

Interfaces, Abstract classes and Implementations

Usually you create class hierarchies like this in order to prepare for future changes:

interface -> abstract class with some implementation -> fully usable class

but if you have only one class extending the abstract one you might get rid of the abstract class and use something like this:

(marker) interface -> implementing class

Why you should get rid of the abstract class:

• less code to maintain
• simpler hierarchy design
• still have the interface to use when referencing implementing classes
• should the time come for more implementations you can refactor your class but that time:

• you will better know what to generalize and what not to
• you will have used the interface so clients no need to be changed
• you saved some time not creating middle classes

But remember this works only if you have clean, well-separated and easy to understand classes. If your class is so complex that takes weeks to understand then:

• you should not have those kind of classes at the 1st place
• but if you have, it's probably better to refactor while you're at it

It seems tempting to create fully generalized implementations but unfortunately you usually don't know how your classes will be used in the future, so skip it - if you can't at least wait for some time before doing so. Sadly I still fell sometimes :(

Of course, if you create a framework or 3rd party library there might be other factors limiting you choices so decide wisely.

More info:
http://www.codinghorror.com/blog/2004/10/kiss-and-yagni.html
http://en.wikipedia.org/wiki/You_ain't_gonna_need_it

Interesting stuff in Java Magazine July/August 2012

Interesting stuff in Java Magazine July/August 2012:

• Secure your web services with Metro, GlassFish, and NetBeans (part 1):
• NetBeans wizards help you to add some security to your web service.
• Debug live Java processes and core files with HotSpot Serviceability Agent:
• This VisualVM plugin lets you debug live and even the crashed (if you have core dumps) Java applications.
• Modify java compiler (javac) to include a new operator:
• It's easy to make small changes in javac leveraging the existing compiler.
• Threading and concurrency in Java EE:
• Don't manage threads, let containers do the work (e.g. use @Asynchronous)
• Wirelessly back up your device’s address book using bluetooth:
• Transfer data over bluetooth in the background.
• Learn Oracle Berkeley DB Java API (part 1):
• Access the embeddable key/value data store from JAVA.

  

Jotted ideas on handling errors

Just jotted down some ideas about how to handle errors

Coding:

•  log the error and the calling parameters - use system console if log fails
•  close/clean-up any resources - don't forget to handle the case if they fail
•  notify the caller about the error
•  handle errors and not swallow them
• think for the edge cases - e.g do you handle 404/301/xxx for a POST ws-call that creates a new entity?

Architecture:

• check for errors in system test - what happens:
• if resource (dbase, network, file system, etc.) is not accessible
• if resource times-out
• if resource fails
• if resource is saturated (e.g disk full, JMS queue full, etc.)
• if a failed resource comes back online - is your system still consistent?
• if rollback or any recovery mechanism fails

         NOTE: the resource can be a 3rd party application or a library

• try to be robust - restart the failing module or stop using it
• think about the whole system and not the components for error testing
• think about the impossible - you might find some cases which are plausible