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.

[Reminder for myself] Performance Monitoring

Determine the points where requests are waiting or slow

If system is busy, deny request at the earliest entry point (e.g. if database is busy then stop accepting requests at the web server)

If under load stop accepting requests and

• process pending requests or
• drop them all or
• restart application 

If adjusting system make sure you're not just moving the load to some other component (e.g from CPU->HDD)

Things to check for

Java:

• Pools size
• Heap utilization
• Garbe collection
• Cache hit ratio
• Messaging systems

Communication:

• Network I/O (bytes r/w, throughput)

OS:

• Disk I/O
• CPU usage
• Memory usage
• Threads usage

Notes on JUnit @After Annotation

Notes on JUnit @After Annotation:

• All methods marked with @After are executed
• The method named tearDown executes even if it's not marked as @After
• @After annotation is not inheritable so you need to add @After if you override the annotated method
• Remember to call super.tearDown if you override tearDown in you class
• For class hierarchies it is best to use different clean-up methods with different names, marked with @After, so they're all called automatically and you won't accidentally override them.