If your application runs as a server, then there will likely be multiple threads (created by the IO libraries) which are used to respond to the incoming requests. This makes it hard to implement a consistent strategy that can handle all uncaught exceptions in a uniform way.

The following program illustrates how to register a default policy for handling uncaught exceptions:

public class TestMain {
  public static void main(String[] args) {
    Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
      @Override
      public void uncaughtException(Thread t, Throwable e) {
        if (e instanceof InvocationTargetException) {
          e = e.getCause();
        }
        //handle all uncaught exceptions here
        System.out.println("Got exception with message: " + e.getMessage());
      }
    });
    throw new RuntimeException("Gonna die!");
  }
}

Setting the default exception handler (line 3) will alter the default behavior for handling uncaught exceptions in the JVM. The implementation of the uncaughtException method (lines 6-10) will now determine what should be done. In this case just the message from the exception will be printed to standard out. A more real-world application of this might be to send a warning message to an operations team, or to take some other remedial action.

The caveat to this approach is that the default exception handler will only be used in cases where neither the offending Thread, or the ThreadGroup that it belongs to, have had their uncaught exception handlers set. If your application manages its own threads, then this will likely not be a problem for you. If your application runs in an application server, then you might well find that the application server has set these handlers already.

I recently has a rogue process (I suspected a virus) on my Mac that was creating thousands of connections out to hosting providers. Luckily I found this fix, which uses lsof to list the network files that are being held open instead. It works a treat:

~$ lsof -i -P

The -i flag restricts output to the networking files, the -P flag prevents well known port numbers from being converted from numbers to text (e.g. 80 -> http). Try it without the -P flag to see the protocol short names.

Using this command, I identified which process was creating the unwanted connections and to dealt with it.

The applications will be named the same as their WAR files and can be accessed using URLs that start with that name. For example, to access index.jsp in the root directory of a WAR file called myapp.war running on Tomcat on the localhost you will need the following URL:

http://localhost:8080/myapp/index.jsp

When there are multiple applications running in the same Tomcat server, they must all have different names.

Any absolute URLs that you need to include in your application must include the applictions name at the start. For example, if in index.jsp we want to reference an image in ‘/images/banner.png’ the absolute URL will be: ‘/myapp/images/banner.png’.

It is bad practice to hard code the application’s name in the URL as this may change for different deployments of the application. Instead, it may be added dynamically using the following scriptlet:

${pageContext.request.contextPath}

So, to add an img tag that refers to the banner image use:

<img src="${pageContext.request.contextPath}/images/banner.png"/>

Alternatively, there are a number of custom tag libraries that will automatically do this for you. Spring MVC ships with such a tag:

<spring:url value='/images/banner.png'>

this will achieve the same results as the scriptlet shown above but is simpler to remember when adding a number of links in your JSPs.

select dbname=db_name(dbid),login=suser_name(suid), #connections=count(suid)
from master..sysprocesses
--where  suser_name(suid) like '%dblogin%'
group by dbid, suid
order by count(suid)

dd/mm/yyyy at hh:mm:ss

System.out.printf("Date: %1$te/%1$tm/%1$tY at %1$tH:%1$tM:%1$tS%n", new Date());

The % characters mark a placeholders for String content, the 1$ indicates that the first vararg should be used for each placeholder (there is only one varag value supplied), the letter ‘t’ in each placeholder indicates a time conversion and the e, m, Y, H, M, S characters indicate what value should be taken from the new Date object for that time conversion.

I’ll demonstrate the technique with an Ant target that I wrote to check whether Ivy had downloaded any jars that had the pattern SNAPSHOT in their name:

<target name="ivy-count-snapshot-jars" depends="init" if="ivy.present">
    <resourcecount property="ivy.snapshot.count">
        <fileset dir="${ivylib.dir}" includes="**/*SNAPSHOT*.jar"/>
    </resourcecount>
    <condition property="ivy.snapshot.present">
        <not>
            <equals arg1="${ivy.snapshot.count}" arg2="0"/>
        </not>
    </condition>
</target>

<target name="ivy-check-snapshot-jars"
        depends="ivy-count-snapshot-jars"
        if="ivy.snapshot.present">
     <echo>WARNING: Project uses ${ivy.snapshot.count} SNAPSHOT jar(s).</echo>
</target>

The first target does most of the work and is used to count the number of jar files with ‘SNAPSHOT’ in their name; it also sets a property if the count is not zero.

The second target is the main one that should be used to perform the check. It depends on the first target (ensuring that the count is done first) and will only then run if the first target sets the ‘ivy.snapshot.present’ property. Thus the warning message will only get echoed if there are snapshot jars in the project.

This can happen in numerous circumstances where you’d like an application to maintain a degree of liveness. I’ve used it recently in an application that needed to run a number of external scripts; if the script does not complete, for whatever reason, the timeout ensures the the calling thread does not get blocked and the remaining scripts can be launched.

Here’s the basic idea:

public class TimeoutDemo {

    //maintains a thread for executing the doWork method
    private ExecutorService executor = Executors.newFixedThreadPool(1);

    public void doWork() {
        //perform some long running task here...
    }

    public void doWorkWithTimeout(int timeoutSecs) {

        //set the executor thread working
        final Future<?> future = executor.submit(new Runnable() {
            public void run() {
                try {
                    doWork();
                } catch (Exception e) {
                    throw new RuntimeException(e);
                }
            }
        });

        //check the outcome of the executor thread and limit the time allowed for it to complete
        try {
            future.get(timeoutSecs, TimeUnit.SECONDS);
        } catch (Exception e) {
            //ExecutionException: deliverer threw exception
            //TimeoutException: didn't complete within downloadTimeoutSecs
            //InterruptedException: the executor thread was interrupted

            //interrupts the worker thread if necessary
            future.cancel(true);

            log.warn("encountered problem while doing some work", e);
        }
    }
}

The doWork method is the one that will actually do some potentially long running work. The doWorkWithTimeout illustrates how the java.util.concurrent classes can be used to prevent the method from taking too long to complete. When calling the latter method, just specify the timeout period in minutes.

The trick here is that the actual work will be done by a dedicated worker thread. The calling thread will handle the timeout management and also handle any exceptions thrown by the worker.

Variations of this pattern can be used for methods that accept parameters (just make them final) and for ones that return values too (just return the value from the future.get(…) call).

cat /proc/cpuinfo | grep processor

each of the processors will be listed in the output. For example, on a server I use the output looks like this:


processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7


So, on this server we can see there are 8 processors available.

The ‘/test’ in the URL will map to a servlet called test. The servlet will dispatch the request to a JSP for rendering that has the following scriplet code in it:

RequestURL: <%= request.getRequestURL() %> <br>
RequestURI: <%= request.getRequestURI() %> <br>
QueryString: <%= request.getQueryString() %> <br>
ServletPath: <%= request.getServletPath() %> <br>
PathInfo: <%= request.getPathInfo() %> <br>
PathTranslated: <%= request.getPathTranslated() %><br>
AuthType: <%= request.getAuthType() %> <br>
LocalAddress: <%= request.getLocalAddr() %> <br>
Method: <%= request.getMethod() %> <br>
RemoteUser: <%= request.getRemoteUser() %> <br>

this is the output generated:

RequestURL: https://localhost:8443/test/welcome
RequestURI: /test/welcome
QueryString: a=1&b=2
ServletPath: /test
PathInfo: /welcome
PathTranslated: C:\projects\testproj\out\artifacts\testapp_war_exploded\welcome
AuthType: CLIENT_CERT
LocalAddress: 127.0.0.1
Method: GET
RemoteUser: Steve