Paging

""

As the number and size of the sessions on a node increases, the ability of the JVM to manage its heap decreases, leading to reduced performance. The physical footprint of the JVM on the box also increases, necessitating the purchase of more memory and larger, faster, more expensive boxes.

By paging out inactive sessions to a cheaper, slower storage medium, space in the more expensive, faster medium (memory) can be preserved. If the session is required after this event, it will be paged back in. If it is not, it may simply expire on disc. (Note that some types of Listener require notification on Session death and may cause the session to be reloaded as it is destroyed).

If a session that is paged out is required by another node, it may be located, read in from local disc by one node, then, without being deserialised (one of the most expensive things that distributed apps commonly do), be moved to the node on which its request has arrived. Here it can be deserialised and used to service the request, remaining on this node, until being required elsewhere, paged out again, invalidated by its application or timed out by the container.

The WADI demo webapp comes with a MemoryEvicter, which is set to sweep memory every 10 seconds and evict sessions which have not been used for more than 10 seconds. We would not recommend these settings for production, but they are useful for demonstration purposes.

Let's try it.

We start a red and green node.

When everything has settled down, create a session on red with e.g. :http://localhost:8080/wadi/session.jsp and wait for between 10 and 20 seconds, until you see red say something like :

2005/12/07 21:56:06:325 GMT [DEBUG] Utils - -motion: 7F9BF12C222FCC99607CAFF98D0EAEF3 : memory -> exclusive disc (12 millis)

red is telling you that it has moved a session out of memory and onto exclusively owned disc - i.e. disc that only red has access to.

Reload your page - adding another cell to the table. red says:

2005/12/07 22:04:17:455 GMT [DEBUG] Utils - -motion: 7F9BF12C222FCC99607CAFF98D0EAEF3 : exclusive disc -> memory (3 millis)

and the session moves up the stack and back into memory.

Let it page out again, then ask for it on green - e.g. : http://localhost:8081/wadi/session.jsp

red says:

2005/12/07 22:56:05:260 GMT [DEBUG] Utils - -motion: C8C00E6E6A7F47C6264F12F39EB7A312 : exclusive disc -> emigration:green (66 millis)

You can see that the session was never deserialised by red - it travelled straight from disc...

2005/12/07 22:56:05:251 GMT [DEBUG] Utils - -motion: C8C00E6E6A7F47C6264F12F39EB7A312 : immigration:red -> memory (39 millis)

...into memory on green, where it was deserialised.

Let it sit on green until it pages out again...then gently (ctl-c) shutdown green:

The session is evacuated directly from disc on green...

2005/12/07 23:00:45:442 GMT [DEBUG] Utils - -motion: C8C00E6E6A7F47C6264F12F39EB7A312 : exclusive disc -> cluster (24 millis)

... to disc on red.

2005/12/07 23:00:45:434 GMT [DEBUG] Utils - -motion: C8C00E6E6A7F47C6264F12F39EB7A312 : cluster -> exclusive disc (5 millis)

Note: No deserialisation occurred at all.