Debugging

This is funny, this is not funny for me.

During this debugging session, I'm continuously guilt ridden for the technical failure is delaying the delivery and it was increasingly time consuming because I needed to question each of my assumptions, that sucks!

After my stress-profile-code-profile-stress cycles I did however learned a bit more about various JVM GC tuning options. Also, that in an overzealous attempt to gain customer delight the code was doing far more than required. I moved a step back and thinking from the usability perspective the problem immediately visible. Thanks to right encapsulation none of the interfaces are breaking and the affected code module could be refactored to fix the performance issue at hand. Further, tweaking the data structure to collect data for generating the performance reports helped us achieve performance gains. Now, we are able to do more with less. The trick is finding the application of technology that makes the most sense for solving your problem at hand.

Looks like my build is complete, let me profile my code again..

Java: Heap crunch

Profile-code-deploy-load was all that I did yesterday and yes it did improve the system performance and technically it did survived the brutal four hour load test without causing OOOE (out of memory exception). The primary hypothesis under which I'm working is that their the certain long living references have retained a sizable of memory. But, I'm sure I'm not exactly able to find the root cause for the system degradation under load. The important observations are;

• We are loading the system using a pattern where we ramp up the load in x minutes and maintain the peak load for y hours and hen ramp down to zero in x minutes.
• The heap usage percentage follows the similar pattern during ramp up, but although the load has plateaued the heap usage percentages continues go higher, while ramp down it eases a bit but never follows the decrease in load and never actually reaches zero or minimum even though there is no activity in the application.
  
• CPU times in GC increases almost linearly albeit with a low gradient and decreases to zero after load completes.

I plan to study GC logs today to understand the system characteristics and fine tune the JVM fit for our purpose and I am sill not sure if I have a memory leak... more later.

Java: Memory leak

Around two years back, when I encountered an article mentioning memory leak in Java, it was little surprising for me and may be author knew about his audience and went ahead to provide one demo program. It surely made me aware of the issue and certain anti-patterns to avoid. Then, I encountered my very own first Java memory leak, and that I my skills are not adequate to handle them. Here, in the current case, when I first observed this phenomenon I went ahead and explicitly 'nulled' my references, which are other wise supposed to go out of scope any ways and hence eligible for garbage collection, but to my frustration this has only marginally helped as the changes have only reduced the rate of memory leak and has not eliminated it. Now I plan to work to work associated anti-patterns like that weak references or references to small living objects held by long living objects etc. Will keep you posted.

Just like that...

We Indians have a tendency to generalize thing so much so that it hardly takes any effort from our side to paint the world in one color. Often as an extension to this exercise to tend o extract particular characteristics of people from a city, and I quite believe that any self respecting engineer from a decent engineering college in India must have had great fun using them to describe their friends. Almost every where you can find 'Baba', 'Guru', 'Ziddi Jat', 'Sirfira Sardar', 'Bihari', 'Taant', 'Gulti', 'Kannadiga', 'Khatta', 'Ghatan'... and the list goes on and on... while I was siting wih some of my senior friends we happened to discuss the changing times.. the arch typical '... those were the day, ...' and one of my senior friend was quite amused and interested to learn the diversity, he then told us that back then during his times such richness and variety was unheard of and as a result of which he would often be referred to as 'Madrasi', now that was real bad as this could be the worst form of identity crisis... he complained that all those from 'North India' used to refer any one down south with the same term and he would never be able to take that... and in order to have revenge on them he would paint them (Northies) as 'Bihari' and that had far reaching affect on them and upon complain he would highlight the similar difference to them... and that probably sowed the seed to heightened verbosity currently in use... seems like this is what is referred to as evolution of language ;)

Disclaimer: With malice to no one... have fun, n'joy!

Failed to connect to remote VM. Connection refused. Connection refused: connect

A lot of time was wasted to resolve the above mentioned error, while I was trying to connect to a remote server using my eclipse IDE in debug mode. Here is the solution;

1. Compile your application using '-g' option. This will generate all the debugging related information, including local variables. By default, only line number and source file information is generated.
2. Launch a new Java Virtual Machine (VM) with the main class of the application to be debugged. For e.g. Launch a new Java Virtual Machine (VM) with the main class of the application to be debugged. For e.g. $> gt; java -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket, server=y, suspend=n, address=8000

Hope that helps.