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.
  • Optional: Increase the frequency of queue synchronization by decreasing the pool’s configuration parameter subscription-ack-interval. This applies only to configurations where server redundancy is used for high availability. Example:

    <!-- Set subscription ack interval to 3 seconds -->
    <cache> 
      <pool ... subscription-enabled="true" 
                subscription-ack-interval="3000"> 
      ... 
    </pool>
    

    The client periodically sends an acknowledgment (ack) message to the server. Each message acknowledges the receipt of many events by the client. Since the server must retain every outbound event in the queue until its receipt is acknowledged, shortening the acknowledgment delay can reduce the average queue size, reducing the amount of server memory used for queueing.

  • 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:

      <!-- Set overflow after 10K messages are enqueued -->
      <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:

      <!-- Set the maximum message count to 50000 entries -->
        <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.