Definition
In order to transfer application state to a joining member of a group pbcast.STATE_TRANSFER has to load entire state into memory and send it to a joining member. Major limitation of this approach is that the state transfer that is very large would likely result in OutOfMemoryException.
Streaming state transfer allows transfer of application state without having to load entire state into memory prior to sending it to a joining member. Streaming state transfer is especially useful if the state is very large (>1Gb), and use of regular state transfer would likely result in OutOfMemoryException. JGroups channel has to be configured with either regular or streaming state transfer. Streaming state transfer was introduced in Jgroups 2.4 release.
Configuration Example
<pbcast.STREAMING_STATE_TRANSFER></pbcast>
Configuration Parameters
| Name | Description |
|---|---|
| bind_addr | The interface (NIC) used to accept state requests |
| bind_interface_str | The interface (NIC) which should be used by this transport |
| bind_port | The port listening for state requests. Default value of 0 binds to any (ephemeral) port |
| buffer_queue_size | If default transport is used the total state buffer size before state producer is blocked. Default is 81920 bytes |
| id | Give the protocol a different ID if needed so we can have multiple instances of it in the same stack |
| level | Sets the logger level (see javadocs) |
| max_pool | Maximum number of pool threads serving state requests. Default is 5 |
| name | Give the protocol a different name if needed so we can have multiple instances of it in the same stack |
| pool_thread_keep_alive | Keep alive for pool threads serving state requests. Default is 20000 msec |
| socket_buffer_size | Buffer size for state transfer. Default is 8192 bytes |
| stats | Determines whether to collect statistics (and expose them via JMX). Default is true |
| use_default_transport | If true default transport is used for state transfer rather than seperate TCP sockets. Default is false |
Advanced
Streaming state transfer provides an InputStream to a state reader and an OutputStream to a state writer. OutputStream and InputStream abstractions enable state transfer in byte chunks thus resulting in smaller memory requirements. For example, if application state consists a huge DOM tree, whose aggregate size is 2GB (and which has partly been passivated to disk), then the state provider (ie. the coordinator) can simply iterate over the DOM tree (activating the parts which have been passivated out to disk), and write to the OutputStream as it traverses the tree. The state receiver will simply read from the InputStream and reconstruct the tree on its side, possibly again passivating parts to disk. Rather than having to provide a 2GB byte buffer, streaming state transfer transfers the state in chunks of N bytes where N is user configurable.
Prior to 2.6.9 and 2.8 releases streaming state transfer relied exclusively on its own tcp sockets to transfer state between members. The downside of tcp socket approach is that it is not firewall friendly. If use_default_transport property of pbcast.STREAMING_STATE_TRANSFER is set to true streaming state transfer will use normal messages to transfer state. This approach besides being completely transparent to application is also firewall friendly. However, as expected, tcp sockets have better performance.
JGroups has a great flexibility with state transfer methodology by allowing application developers to implement both byte based and streaming based state transfers. Application can, for example, implement streaming and byte based state transfer callbacks and then interchange state transfer protocol in channel configuration to use either streaming or byte based state transfer. However, one cannot configure a channel with both state transfers at the same time and then in runtime choose which particular state transfer type to use.
Comments