Exception handling with Spring RestTemplate

Exception handling with Spring RestTemplate

<T> ResponseEntity<String> doPost( String uri, 
                                   T request, 
                                   HttpStatus expectedStatus) 
{
    ResponseEntity<String> response = null;
    try 
    {
        response = _restTemplate.postForEntity(uri, request, String.class);
    } 
    catch (HttpStatusCodeException e)  // thrown by DefaultResponseErrorHandler
    { 
       // Server Response: 40x , 50x
    } 
    catch (ResourceAccessException e) // thrown by RestTemplate.doExecute
    { 
        // I/O error, including marshaling
    }
    catch (Exception e) 
    { 
        // other error
    }
    return response;
}

A Littel Junit Helper: org.junit.Assume

By using the JUnit's AssumeXXX methods, tests can be run based on specific assumptions.

If the assumption is not met the test will not run but will be shown as passed.

As Explained by an example:

 @Test
 public void checkNtfsFileSystem() {

    FileSystem fileSystem = FileSystems.getType()

    assumeTrue(fileSystem == NTFS); // run test only if filesystem is NTFS

    //
    // do test
    //
 }

How to Stop Embedded Tomcat

The following lines stop Tomcat and release the used ports and resources:

tomcatServer.stop();
tomcatServer.destroy();

Hazelcast Notes (Map.put and Mapstore.load; write-back and bulk persistence methods)

Remember if you have a map that is backed by database the calls to Map.put will issue
Mapstore.load as the put should return the old value.

You can use Map.set to circumvent this behavior; the same goes for remove and delete.

Also note, that for write-back persistence MapStore.store and MapStore.load methods might be used if there are only some items to persist.

Sucessfull Java Socket Send with Broken Connection

With Java sockets it's possible that the socket write method is successful even if the network is down.

When Java issues socket write   the request is passed forward to the Windows socket send function. The documentation of send says that

The successful completion of a send function does not indicate that the data was successfully delivered and received to the recipient. This function only indicates the data was successfully sent. 

and an older version also says

If data for which the peer protocol has buffer space cannot be successfully transmitted within a reasonable length of time, the connection is considered broken and subsequent calls will fail with the error code set to WSAETIMEDOUT.

For some operating systems  "successfully delivered" just means that the data was passed into a buffer in the network stack, which will handle the transfer.

TCP connection is open unless it's closed or terminated:

• application calls socket close
• application crashes and OS closes the socket
• OS closes the socket due to an event (e.g restart)

So if the network becomes disconnected the connection remains open if there's no data sent; there's no way to detect network hiccups just by listening to incoming connections.

TCP usually provides keep-alive messages to detect network failures.

References:

• SocketOutputStream.c
• MSDN Send
• TCP Timeout and Retransmission
• UNIX Socket FAQ

Cacheable HTTPS response

Some browsers (e.g Internet Explorer) cache content even if accessed via HTTPS, thus  if server returns sensitive information this may be retrieved by other users who have access to the browser.

To fix it, add the following headers into response:

Cache-control: no-store 
Pragma: no-cache 

More info here.

Servlet Session Tracking with cookies (JSESSIONID)

A quick recap on how session tracking works with cookies:

A) first request from client

• New session is created only if HttpServletRequest.getSession is called
• Session id (JSESSIONID) is generated 
• Response contains JSESSIONID cookie
  (e.g. Set-Cookie: JSESSIONID=762F504BFD0E69A5A8C8F9B53DDD42BB)

[TOMCAT] The Request.doGetSession creates session using StandardManager and then sets the JSESSIONID to a random number generated by ManagerBase.generateSessionId. The cookie itself is added to the response using Response.addSessionCookieInternal.

B) subsequent requests from client

• HttpServletRequest.getSession returns the session for the client based on the value of the JSESSIONID cookie
• HttpServletRequest.isRequestedSessionIdFromCookie returns true
• Response may but typically does not contain JSESSIONID cookie anymore as it was sent in the 1st response

[TOMCAT] CoyoteAdapter.service uses CoyoteAdapter.parseSessionCookiesId to get the value of the JSESSIONID cookie and then binds the session id to the request using Request.setRequestedSessionId so that Request.doGetSession can find the session later using StandardManager.findSession.

Simple Workflow Engine

The other day I stumbled upon a little Java library called 'Simple Workflow Engine' that is pretty neat and simple to use. As I will need something in the near future that can be used to orchestrate some  sequential tasks I will definitely give it a go a report how it performed.

Mapped Diagnostic Context (MDC) in Logback

Mapped Diagnostic Context (MDC) is a feature in LogBack that allows you to store some information in a context and have them shown in the log file. It's especially useful if you need some high-level information (e.g. request address) shown in every log item.