views:

39

answers:

1

Hello,

In order to debug failing requests I would like to print all information coming from HttpServletRequest.

Now, it's possible that a request will partially fail (for ex. Several matches are successful, yet one has failed) in which case I would like to catch the exception in the internal method that failed, print the error + the ServletUtil.toStringHttpServletRequest() and continue providing service (degraded but still useful vs. complete request failure).

Our current implementation either catches the exception and prints dumb info ("getRules failed") or throws the exception all the way to doGet() (effectively canceling service for the user) where as in doGet() I have access to HttpServletRequest where I can print at the relevant debug info (headers, parameters...).

Passing HttpServletRequest to every function called during the request that might fail seems a bit ugly, I will do it if no other elegant solution will pop up.

Making a before head ServletUtil.toStringHttpServletRequest() and storing it in a ThreadLocal map would be wasteful both in memory and CPU time. For some reason it feels wrong to store the HttpServletRequest object in ThreadLocal (please correct if I'm wrong).

Debug information is written both to local machine log and is emailed directly to devs (Great work log4j TLSSMTPAppender), so logging in several places won't be practical (Will need to assemble several emails to understand what's going on) and ssh'ing into the server is old age :) (We're all cloudy here... server might not exist by the time I get to look at the error)

So, my solution is gaining access to a "PrintErrorUtility" (TODO: better name it). That will receive (String errorMsg, Throwable t, HttpServletRequest) which will print the error together will all the relevant info... This will be called from internal try {} catch blocks that will notify about the error but will not cancel the request because of it.

Obviously I'm taking about servers running in production.

Comments? Please advise.

Thank you, Maxim.

A: 

Do this task in a Filter after the FilterChain#doFilter() call. The ServletRequest object is already there. In the business code where this exception is to be suppressed gracefully, store the exception as a request attribute and just let the Filter check/grab it from the request.


Update: as per the comments, here's an example:

public class Context { 
    private static ThreadLocal<Context> instance = new ThreadLocal<Context>();
    private HttpServletRequest request;
    private List<Exception> exceptions = new ArrayList<Exception>();

    private Context(HttpServletRequest request) {
        this.request = request;
        this.request.setAttribute("exceptions", exceptions);
    }

    public static Context getCurrentInstance() {
        return instance.get();
    }

    public static Context newInstance(HttpServletRequest request) {
        Context context = new Context(request);
        instance.set(context);
        return context;
    }

    public void release() {
        instance.remove();
    }

    public void addException(Exception exception) {
        exceptions.add(exception);
    }
}

And here's how to use it in your controller servlet:

Context context = Context.newInstance(request);
try {
    executeBusinessCode();
} finally {
    context.release();
}

And here's how you could use it in the executed business code:

} catch (Exception e) {
    Context.getCurrentInstance().addException(e);
}
BalusC
OK, but in order to store the exception at the request attribute I need to have access to the request object, doesn't it brings us back to square 1? (Unless I've missed something, in which case please correct my mistake) EDIT: I would pass a map of <Exception, String) which will collect all exceptions found -- That is actually a pretty good idea! but still this is one extra parameter for each method called, not sweet at all :(
Maxim Veksler
Are you using a specific MVC framework or a homegrown one? Most of existing MVC frameworks have a threadlocal context from which you can grab the "underlying" raw request/response objects.
BalusC
No MVC, it's a backend server. All the server does is calculating match per request, no frameworks purely our code.
Maxim Veksler
Well, you might consider to homegrow a threadlocal "context" which provides access to request/response. You only need to make sure, **sure**, that this is been released at end in **any** case. The `finally` block of the `try` block wherein the business action is to be invoked is good for this. The average servletcontainer namely uses a thread pool and thus reuses threads.
BalusC
Hi, the system runs on tomcat 5.5 (Debian). That's one of the reasons I don't like thread local (so much). Could you please provide a code example for such ThreadLocal based context approach ?
Maxim Veksler
BalusC thanks for the example, the code looks elegant. Regarding the release of the context, should it be released after the HTTP thread dies? Why the requirement for the finally() clause?
Maxim Veksler
In servletcontainers, the thread usually never dies. The thread will be pooled for reuse for subsequent requests. The `finally` is to **ensure** that it will be released regardless of exceptions.
BalusC