Limit the Server's Subscription Queue Memory Use

These are options for limiting the amount of server memory the subscription queues consume.

Optional: Conflate the subscription queue messages. See Conflate the Server Subscription Queue.
Optional: Increase the frequency of queue synchronization. This only applies to configurations where server redundancy is used for high availability. Increase the client’s pool configuration, subscription-ack-interval. The client periodically sends a batch acknowledgment of messages to the server, rather than acknowledging each message individually. A lower setting speeds message delivery and generally reduces traffic between the server and client. A higher setting helps contain server queue size. Example:
```

<cache> 
  <pool ... subscription-enabled="true" 
            subscription-ack-interval="3000"> 
  ... 
</pool>
```
You might want to lower the interval if you have a very busy system and want to reduce the space required in the servers for the subscription queues. More frequent acknowledgments means fewer events held in the server queues awaiting acknowledgment.
Optional: Limit Queue Size. Cap the server queue size using overflow or blocking. These options help avoid out of memory errors on the server in the case of slow clients. A slow client slows the rate that the server can send messages, causing messages to back up in the queue, possibly leading to out of memory on the server. You can use one or the other of these options, but not both:
- Optional: Overflow to Disk. Configure subscription queue overflow by setting the server’s client-subscription properties. With overflow, the most recently used (MRU) events are written out to disk, keeping the oldest events, the ones that are next in line to be sent to the client, available in memory. Example:
```

<cache-server port="40404"> 
  <client-subscription 
    eviction-policy="entry" 
    capacity="10000" 
    disk-store-name="svrOverflow"/> 
</cache-server>
```
- Optional: Block While Queue Full. Set the server’s maximum-message-count to the maximum number of event messages allowed in any single subscription queue before incoming messages are blocked. You can only limit the message count, not the size allocated for messages. Examples:
  XML:
```

  <cache-server port="41414" maximum-message-count="50000" />
```
  API:
```
Cache cache = ...; 
CacheServer cacheServer = cache.addCacheServer(); 
cacheServer.setPort(41414); 
cacheServer.setMaximumMessageCount(50000); 
cacheServer.start(); 
```
  Note: With this setting, one slow client can slow the server and all of its other clients because this blocks the threads that write to the queues. All operations that add messages to the queue block until the queue size drops to an acceptable level. If the regions feeding these queues are partitioned or have distributed-ack or global scope, operations on them remain blocked until their event messages can be added to the queue. If you are using this option and see stalling on your server region operations, your queue capacity might be too low for your application behavior.