I must say, I am quite fortunate to have got some good opportunity to try and run our j2ee application on IBM AIX OS.

I deployed the application and started the application. All went well until I hit upon the very famous “Core Dump – Dump Handler is Processing Signal 11”. I had to spend almost 2 to 3 hours weaving thru lots of newsgroups on the internet and figured out that the FileDescriptor Upper Limit was not set(which means its set to unlimited) there is a problem in AIX in performing a malloc() to obtain a memory segment.

This is what I learnt

This is due to an AIX issue when WLS attempts to perform a malloc() to obtain a memory segment. The WLS Posix Socket Muxer code (NativeIO and stuff) does a malloc based on the FDLimit. If it’s unlimited, AIX 4 and 5 tend to throw a malloc exception. WebLogic Server WLS made it 1025, which the user can set higher if desired.

Check out this URL for more details…

Sometime back I had blogged about ClearWatch which is a very handy SSL sniffing tool. Here, you require the Private Key of the Server for decrypting the HTTPS packets.

However often, I end up in situations having to sniff the SSL traffic of Production Systems, where I donot have access to the Private Key.

Now, I have come across another excellent tool called BurpSuite. This tool can do more in the sense that, it can sniff SSL Packets without having to provide the Private Key of the Server. Also, it allows to intercept requests/responses with specific header information and allows us to change the header data whenever required. This tool basically is a special proxy server. One has to configure the browser to go thru this proxy server for sniffing purposes.

Check it out!

Boy! Thanks a ton to Venkat, for letting me know of such a conference with my favorite speakers – Dave Thomas, Kent Beck etc. Since am anyway going to the US in March 2006, am planning to extend my stay in US and make sure I attend waterfall2006 conference.

I shall certainly share my experiences from the conference in my forthcoming blogs 🙂

I have a great respect for Mozilla applications after having successfully making our company’s product “Firefox compliant“. Our experience revealed that, IE is very leniant and hence does not scream if we write non standard html/javascript codes. However, all we had to ensure is to make the codes standard compliant, then it automatically worked both in Firefox as well as IE.

With the same confidence, I upgraded my Firefox to the latest and great v1.5. Guess what, lots of application’s functions started to misbehave. One main issue is that we often get “Script is taking long time to complete and is not responding. Do you want to stop or continue the script?“

After lots of trial and error, I tried a hack which worked for me…

Basically, in the script function, I am setting the window.status to some value with the assumption that the browser should not scream as long as there is some update happening in the screen. Guess what? this hack worked!!!

Well, the happiness was very shortlived when I found that there is an option in Firefox called “change the status bar text” under “Advanced Javascript settings” and to add to my depression, the option is by default UNCHECKED.

Therefore, though I have a hack, the user has to change this setting for my application to work fine in Firefox 1.5.

Hope someone finds a permanent solution to this issue, or is it a Firefox issue, that one day Firefox will fix it!

After long follow up from Venkat, I finally managed to open source our famous inhouse Load Test Conductor tool to sourceforge. Hope to add more features and fixes soon!

Before going into details let us observe the below code

try {
conn = getDBConnection();
conn.setAutoCommit(false);
PreparedStatement ps =
conn.prepareStatement(Some Update Sql 1);
ps.executeUpdate(Some Update Sql 1);
conn.commit();
ps.executeUpdate(Some Update Sql 2);
} finally {
try {
if (conn != null) conn.close();          
} catch (SQLException ex) {
Debug.logError(ex, "Some Error Message");       
}
}

What will happen to the second sql updation …? Will it get committed or rolled back? There are two flavours of answer to this…

1. When connections are not pooled
   In this case, Connection.close() method commits all the uncommitted statements (As per 9i Oracle JDBC Driver).
2. When connections are pooled
   In this case, Connection.close() really does not close the connection but releases it to the connection pool for reuse by somebody else. In this case, situation is bit undeterministic. The outcome purely depends on how the Pool manager manages. We found in Weblogic pool management, Connection.close() results in all open cursor closure and resetting of AutoCommit flag. But the uncommitted transactions are neither committed nor rolledback. All the exlusive locks obtained for the previous updation will remain alive. This behavior continues until the same connection from the pool is assigned for somebody else and he either commits or rolled back.

Now, Consider the below piece of code,

 PreparedSQLRunner ps = null;
try {
conn = getDBConnection();
conn.setAutoCommit(false);
PreparedSQLRunner.executeUpdate(Some Update Sql 1);
conn.setAutoCommit(true);
   ps = new PreparedSQLRunner();
ResultSet rs = ps.executeQuery(Some Select Sql);
   ....
} finally {
try {
if (ps != null) ps.close();            
} catch (SQLException ex) {
Debug.logError(ex, "  ");         
}
try {
if (conn != null) conn.close();            
} catch (SQLException ex) {
Debug.logError(ex, "  ");         
}
}

In the above context, what would happen to the uncommitted update sql ?

As per JDBC API specification, when we change the Auto Commit flag of a Connection object from false to true, the next immediate statement on that connection, will commits all its previous uncommitted operations (that were happened with Auto Commit Flag set false). So, the call to executeQuery method, results in the committing of the previous uncommitted updation in addition to its expected service.

Boy! couple of months back I had encountered an issue where my application which is running as Windows NT Service, always used the Locale settings thats entirely different from what is set in the control panel by the logged in user.

I thought if I had provided an User Account to be used as the credentials for the service, then the windows service might use that particular user’s locale settings. But Hard Luck!

Later on further weaving thru the Windows Registry, realized that windows captures the Locale Settings that I had provided during the initial Installation of the WinXP Operating System.

This basically means Windows maintains TWO Locale information, one about the logged in user and the other which is the default that was provided during Windows Installation.

The following Registry Key stores Current Users Locale Configuration
HKEY_CURRENT_USER\Control Panel\International

The following Registry Key stores the Default Users Locale Configuration
HKEY_USERS\.DEFAULT\Control Panel\International

Tough Find !!!

Recently, we had our application database upgraded from Oracle 9i to Oracle 10g. And therefore we also upgraded oracle jdbc thin driver accordingly.

We were surprised by a nice “ArrayIndexOutOfBoundsException” when reading data from the ResultSet.

After lots of research, I learnt about an inherent bug in Oracle 10g thin driver where if we set the fetchSize on the PreparedStatement we have to set the same fetchSize on the ResultSet as well. This certainly was not the case with previous versions of Oracle.

To my knowledge this bug is not fixed yet. The workaround until then is to set the FetchSize on the ResultSet object whenever you set the FetchSize on the PreparedStatement.

Code snippet:

PreparedStatement ps = conn.prepareStatement(“Select * from some_table”);
ps.setFetchSize(20);
ResultSet rs = rs.executeQuery();
//rs.setFetchSize(20); //Uncomment this line to reproduce the issue.
while (rs.next()) {
// … process the row
}

Recently, I was stuck with an issue that I badly wanted to sniff the SSL Packets received from my web application. Thanks to the ClearWatch tool.

The tool from Covelight allows you to sniff HTTP packets encrypted with SSL as well. All you need is to have the Private Key of the Server.

The tool is available for download from http://www.covelight.com/downloads.php