Can I log when my JAX-RS application can't send its response? (How?)

Question

I'm running a JAX-RS web service on EE6 (EAP 6.4, if that plays a role).

I'd like to be able to tell if the response was delivered to the client, but I can't seem to be able to pick up on errors.

I wrote a sandbox example:

@POST
@Path("/delay")
@Produces(MediaType.APPLICATION_XML)
public String justWait(InputStream is) throws IOException, InterruptedException {
    String theString = IOUtils.toString(is, "UTF-8");
    log.info("Received body: " + theString);
    log.info("Now waiting a bit");
    Thread.sleep(5000);
    log.info("Back, sending respoonse.");
    return "<OK/>";
}

But whatever I do, whenever I send a POST, the log output is pretty and clean. Hit "abort" in the REST plugin? Nothing. Close the browser? Silence. Use curl and Ctrl-C it halfways? Nøpe.

I'm logging all incoming request using a javax.servlet.annotation.WebFilter, and I can also see the outgoing response, but it's of course after this logging that the delivery would fail.

How can I tell that my response wasn't sent?

If there are solutions in EE7, I'd also like to hear about them. We'll upgrade soon anyway.

Answer 1

Try using a servlet filter to trap exceptions when the socket is closed prematurely. Make sure it's first in your web.xml.

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;

public class StackHunterServletFilter implements Filter {

    @Override
    public void init(FilterConfig config) throws ServletException {
    }

    @Override
    public void destroy() {
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {

        try {
            try {
                chain.doFilter(request, response2);
            } catch (Throwable e) {
                e.printStackTrace();
                throw e;
            }
        } catch (IOException e) {
            throw e;
        } catch (ServletException e) {
            throw e;
        } catch (RuntimeException e) {
            throw e;
        } catch (Error e) {
            throw e;
        } catch (Throwable e) {
            throw new ServletException(e.getMessage(), e);
        }
    }

}

Answer 2

hmm, sorry, I see. You can use a filter as you're already using, maybe even add a separate ResponseFilter capturing all actual responses (see for instance Logging request and response in one place with JAX-RS) sent from your side which could be said to prove exactly that. Proving they actually recieve your responses is quite different; if the customer is accessing your API programmatically, there is no other way then getting grips on their transport logging, or, make a customer visit and help them set it up : you do have the common interest of solving this, right? It they just browse your API then.. I dunno, the former is your only option?

• just some more comments, following your comment:

yep, as I said, the filter, even if working, will not say anything regarding the actual delivery of your responses. for example, I'm currently sometimes thrown into this thing now and then where we have über restricted point-to-point access over VPN with SSL-verification both ways, heavy firewalling on both sides and then, on the way in, there are a number of proxies between us and our destination. in most cases, we act as clients and it has happened many times that our fw has had some kind of problem or some of our proxies have been misconfigured or down or the SSL-certs are out of date or just.. network issues on our side. in these cases the remote server has no way of telling anything went wrong, they just respond - it is you, the client, who has the problems and it is on your side errors will popup whenever you cannot read responses. so.. there is not really any point avoiding the obvious here I guess, first thing you do is ask them well, "how did you notice there was no response"? timeouts/socket closed? different type of errors usually indicate the domain from where it arose. then you just follow the trace and you will find the point of termination. however, in your case it seems to happen.. "sometimes" rather then your network toggling "off" - then I would, if the error logs they sent me didn't tell me exactly what was going on, ask the customer what their client is actually doing. would it be possible that they connect single-thread and another request is issued before the current response is read? stranger things (and more horrid code) has been seen to execute, right? I think I'm just saying that you should focus not on your API, it probably works, focus on the actual client which, in contrast to your server, should do two things instead of just one.