Things that cause increasing Handles

a) Uncaught Exceptions but handled higher up
b) Returning a null when the Method strictly returns an ArrayList<>. And then validating the ArrayList<> with == null instead of isEmpty();
c) Failure to close Db Connection or possible resource handles
d) Using a scanner class, and not using an iteration to next()

That’s all I can think of for now()!

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

db4o TP is a nightmare, implement IStatefulJob

In trying to make db4o Transparently Persistent, I’ve given up.
The documentation is not as clear as I believe it should, the documentation (Tutorial pdf) appears to be incorrect or outdated.

Here is my forum question on how to actually turn on TP successfully.

I’ve just managed to solve my problem simplistically using Quartz: (wow, one word, one line)
public class Starter implements Job, StatefulJob {

THE END

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

db4o Transparent Persistence

So after much haggling of code, testing and pointless circumspection.
I’ve come to realise db4o by default, does not allow for Transparent Persistence of object modification across threads or instances.
So even if  you .store() or .commit(), you will end up with a possible ill-formed object or inconsistent data object.

So after much searching and peering into the nature of the beast, to solve this problem you need to turn on TP (Transparent Persistence).
Unfortunately, it’s a ant build script…….so exciting…..anyways, here’s the link: TP

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

Solving a Bug

I have spent close to 1 week trying to resolve a bug that I was using in a product which proxies calls from java to win32.
Basically the bug caused the JVM to crash, with an “Memory violation” error.

The project fell out of it’s deadline, and though amidst this pressure, and the failing to deliver on time I learnt some fundamentals to keep a cool head.

When you dealing with a BUG of unknown characteristic or a pure anomaly (by appearance), this is my advice:
– Get done to where the problem lies
– If you don’t understand that line of code or function, spend time with it.
– Live inside the debugger, step through the code, remote debug, understand the problem.
– if you become disillusioned, don’t make large changes. Where the bug might point to a problem, might not be the real problem, but only a symptom of a problem.
– Track you changes, and be able to switch between them.
– Change small pieces, implement, test and test again.
– When you lose hope, BE BRAVE! This isn’t magic. Go back get a Performance monitoring tool like Performance Explorer, review your Handles, Memory, Threads etc.
– Simplistically, ensure you understand every piece of code you used (as sometimes we tend to copy and paste without understanding)
– Spend the hard miles understanding instead of re-arranging and testing.
– Don’t try reach for the tree tops, when you could just cut down the TREE.

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

What is a handle?

In computer programming, a handle is a particular kind of smart pointer. Handles are used when an application references blocks of memory or objects managed by another system, such as a database or an operating system.

While a pointer literally contains the address of the item to which it refers, a handle is an abstract reference controlled by a separate system; its opacity allows the referent to be relocated in memory by the system without invalidating the handle — impossible with pointers. The extra layer of indirection also increases the control the managing system has over operations performed on the referent.

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

Basic Garbase Collection

In trying to resolve an issue with my existing project (what appears to be an intermittent bug), I’ve been forced to consider and understand some deeper follicles of the Garbage Collector *grunt* (in this case, Java)

So it appears that most distribution of objects across the life of an application have what appear to be a more or less consistent normative curse (the one above).
As such, within this distribution, the life of objects are more less determined and it is this concept, that forms the algorithm for the garbage collector.

Garbage collection occurs in generations, that is, the garbage collector cleans up when the generation fills up.
Object are allocated into generations. When the young generation fills up, it causes a minor collection.
Minor collection can be optimized assuming a  high infant mortality rate.
A young generation full of dead objects is collected very quickly. Some surviving objects are moved to the tenured generation.
When the tenured generation is collected, there is a major collection (this is often slow because it contains live objects).

I know this sounds obvious, but tuning of the Garbage collector should only become necessary when the garbage collector is a bottleneck.

At virtualization, a maximum address space is virtually reserved but not allocated to physical memory (unless it is needed).
The complete object memory can be divided into the young and tenured generations.

The young generation consists of “eden” plus two survivor spaces. Objects are initially allocated in eden.
You might have seen this before:

SPAN { font-family: “Courier New”; font-size: 10pt; color: #000000; background: #FFFFFF; }A { text-decoration: none; font-weight: bold; color:#000000;}Heap
def new generation total 960K, used 305K [0x22990000, 0x22a90000, 0x22e70000)
eden space 896K, 32% used [0x22990000, 0x229d9df8, 0x22a70000)
from space 64K, 15% used [0x22a70000, 0x22a72828, 0x22a80000)
to space 64K, 0% used [0x22a80000, 0x22a80000, 0x22a90000)
tenured generation total 4096K, used 3365K [0x22e70000, 0x23270000, 0x26990000)
the space 4096K, 82% used [0x22e70000, 0x231b9760, 0x231b9800, 0x23270000)
compacting perm gen total 12288K, used 5241K [0x26990000, 0x27590000, 0x2a990000)
the space 12288K, 42% used [0x26990000, 0x26eae7f0, 0x26eae800, 0x27590000)
ro space 8192K, 63% used [0x2a990000, 0x2aea8810, 0x2aea8a00, 0x2b190000)
rw space 12288K, 53% used [0x2b190000, 0x2b7fd300, 0x2b7fd400, 0x2bd90000)

Objects are copied between survivor spaces in this way until they old enough to be tenured.
I think that’s enough for now!

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

Basics in Code Troubleshooting


Sometimes you get so deep into the code you fail to see the simple things.
You end up reaching up into the trees, instead of just chopping them down.

I recently finished a piece of code and for some reason, at random intervals my code would completely fall apart, killing my JVM.
Now this threw an error that sent me on absolute wild goose chases, simply because the error did not match what was happening, which is usually the case when you are not clearing memory as you should be (win32 api).

Using the ever handy SysInternal Process Explorer I was able to pick up an ever-incrementing set of handles and thus the problem to my JVM deciding it needed a break.

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

Wise Lesson of the Day: Calling a batch file from a Batch File….

A. Simply entering a batch file’s name within another batch file will run the batch file you want to call.
However, after the called batch file completes, it won’t pass control back to the calling batch file.
Thus, the calling batch file will be incomplete.
To call a batch file and have the file return to the calling batch file after the called file completes, use the call command.

WindowsITPro

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone