XmlRpcStreamServer.java contains the following code in execute():

                        try {
                                istream = getInputStream(pConfig, pConnection);
                                XmlRpcRequest request = getRequest(pConfig, istream);
                                result = execute(request);
                                istream.close();
                                istream = null;
                                error = null;
                                log.debug("execute: Request performed successfully");
                        } catch (Throwable t) {
                                log.error("execute: Error while performing request", t);
                                result = null;
                                error = t;
                        } finally {
                                if (istream != null) { try { istream.close(); } catch (Throwable ignore) {} }
                        }


On initial inspection this looks reasonable, the problem is that if the server calls a handler which throws an application-level exception which will result in the XMLRPC <fault> response being returned to the client, it ends up triggering the log.error() action. This causes lots of spurious error messages in logs - at an application level it may be necessary to throw exceptions to trigger a <fault> response to the client, this doesn't mean there is any sort of fault that XMLRPC should concern itself with.

There should be different mechanisms for handling application-level exceptions, which XMLRPC should propagate as <fault> responses and not otherwise concern itself with, and true XMLRPC exceptions (e.g. no response from remote end) which it should deal with. At present there is no distinction between these two types of error.