Sid's Blog

Throw null.

2008-06-24T12:27:57-07:00

Eugene posed an interesting question about Alex' blog entry on why the following code does not require main method to throw throwable -

  public class Weird {  
    public static void main(String[] args) {  
      throw null;  
    }  
  }

The fact that it throws a NPE has been discussed on Alex' blog.
But the reason(or my hypothesis) why the compile dos not require you to add a Throwable to throws clause is as follows -

The null reference can always be cast to any reference type.
Checked Exceptions should be declared in the throws clause.
RuntimeExceptions and Descendants are exempt from the above requirement(2)
Rephrasing 2 and 3 as "if the type is not an instance of RuntimeException", which translates to the following code -
```
if(!(type instanceof RuntimeException)) {
 //check throws clause for validity
}else {
 //dont check.
}
```
and we can see that 'null' case would go to the else block.

Q.E.D. ? (you decide)

Dont put a lot in IN.

2008-06-12T10:30:49-07:00

So in case people were wondering if application alerts are a good idea; heres a sybase database oddity/limitation/defect which we noticed via our alerting mechanism.

This defect was not discovered during development, slipped through QA and did not show itself in production for quite a few months. And then suddenly one day it showed up in the alerts (see below) -

[com.company.servlets.GenericServlet] request string--->http://service.company.com:8080/category/get_ante/attrs?null org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not execute query; uncategorizedSQLException for SQL [select this_.atom as atom4_0_, this_.dte_orig as dte2_4_0_, this_.dte_update as dte3_4_0_, this_.country_code as country4_4_0_, this_.ante as ante4_0_, this_.updated_by as updated6_4_0_ from category_ante_intl_atom this_ where this_.atom in (?, ?, ?, ?, ?, ?, ?, ...1024 of them !!)];

SQL state [ZZZZZ]; error code [404]; Too many ANDs or ORs in expression (limit 1024 per expression level). Try splitting query or limiting ANDs and ORs.
So anyone who has used hibernate ("Restrictions.in") or even plain sql with an IN clause should be careful if the method takes an unbounded list and puts them inside the IN clause. Infact anyone writing one of those innocent looking DAO method which takes in a list of ids and returns a bunch of Objects could be guilty of causing this if they are not careful.
This is one of those unobvious scaling bugs which people run into (a similar famous scaling bug is documented here - BinarySearch )
And one of the criticisms of hashCode is the return type int instead of a long (again related to scaling).

This defect (or 'limitation' if you want to be polite) exists in sybase 12.5 and has been corrected in more recent versions of sybase ase. Also in Oracle this limit is even less, around a 1000 ! see here --> Oracle forum link.
So for portability we might have to keep that in mind.

Log4j SMTPAppender for email alerts

2008-05-27T13:57:42-07:00

We recently put a new application in production under a tight schedule. One of things we wanted to track was the number of errors which were happening at runtime,so we could get some feedback on the frequency with which they happened.

A couple of other members in the team had used log4j's smtpappender for this before. So we hooked it up to send us email alerts for each log.error statement in our code (Application errors). It was very interesting to see how our dependencies failed us and what bugs had gotten past QA.

Sample log4j configuration for the SMTP appender - 
  <appender name="SMTP" class="org.apache.log4j.net.SMTPAppender">
    <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
    <param name="Threshold" value="${log4j.email.threshold}"/>
    <param name="To" value="${log4j.email.to}"/>
    <param name="From" value="${log4j.email.from}"/>
    <param name="Subject" value="Service Error - ${machineid}"/>
    <param name="SMTPHost" value="hqintmail.org.com"/>
    <param name="BufferSize" value="10"/>
    <layout class="org.apache.log4j.PatternLayout">
      <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c] %m%n"/>
    </layout>
  </appender>

For example one of things we noticed was a couple of the webservices we depended on was not very reliable and crashed (returned no data) for atleast 10-15 times in the day !

Since this was a customer facing webapp the errors were appropriately handled on the UI but having this alerting turned on, enabled us to proactively track issues before customers actually reported them. There were a couple of situations in which it didn't exactly do what we wanted. For example, when one of our enterprise databases went down for a couple of minutes, our inbox got flooded with alerts within minutes.

But on the whole, things were going well until our mail server changed. Log4j configuration still had the old mail server name. And since the appender could not send out the email alert, it relentlessly kept trying to do so making the box totally unresponsive and even dropping existing client connections Googling further on the problem I was able to find this (just thought I would pass it on) – java forum thread discussing log4j

So if you worry about high availability then this is one of the things which could expose a chink in your design and eventually we are moving away from using this as our alerting mechanism( though using asyncappender could mitigate some of the risk) as we wanted more features from our alerting.
A couple of features which would be nice to have -

Cumulative alerting - Tell me when a problem(database down) starts and when it subsides instead of each failed attempt.
Selective alerting - Ability to ignore some alerts without requiring a code change
Routing - Ability to route different kinds of alerts to different emails (out of the box).
Performance and Availability - It should not affect the performance or the availability of the application.
Statisitcal Analysis of Alerts - Basically fancy charts and historical analysis.

Hello World

2008-05-14T16:12:00-07:00

I say Hello - You say Good-bye