Salesforce wsc hacking: adding RequestTimedOutException

I have a number of situations where a RequestTimedOutException would be appropriate instead of just a ConnectionException when SoapConnection.send() encounters a SocketTimeoutException.

This would ease retry implementations (related to timeouts) in that they would only have to consider a special type of exception and does not have to revert to parsing exception messages.

If a RequestTimedOutException extends ConnectionException the handling of SocketTimeoutException in the SoapConnection class can be done without changing the api. It is a simple matter of changing the type of exception thrown as response to SocketTimeoutExceptions.

E.g. in SoapConnection:

112
113
114
115
116
117
        } catch (SocketTimeoutException e) {
            long timeTaken = System.currentTimeMillis() - startTime;
            throw new RequestTimedOutException("Request to " + url + " timed out. TimeTaken=" + timeTaken +
                    " ConnectionTimeout=" + config.getConnectionTimeout() + " ReadTimeout=" + 
                    config.getReadTimeout(), e);
        }

And the RequestTimedOutException, e.g. at the bottom of SoapConnection:

    public static class RequestTimedOutException extends ConnectionException {
        private static final long serialVersionUID = 1L;
 
        private RequestTimedOutException(String message, Exception e) {
            super(message, e);
        }
    }

WSC issue 67.

About Jesper Udby

I'm a freelance computer Geek living in Denmark with my wife and 3 kids. I've done professional software development since 1994 and JAVA development since 1998.
This entry was posted in Java, Salesforce and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.