0

The entries in the GemFire region need to be automatically destroyed based on the TTL configured using entry-time-to-live.

As per the GemFire documentation:

By default, one thread handles expiration, and it is possible for the thread to become overloaded when entries expire faster than the thread can expire them. If a single thread is handling too many expirations, it can result in an OOME. Set the gemfire.EXPIRY_THREADS system property to the desired number when starting the cache server.

Based on this, the property - gemfire.EXPIRY_THREADS has been set in the start server command as:

start server --J=-Dgemfire.EXPIRY_THREADS=10 ...

The server logs show:

Command Line Parameters:
    ...
    ...
    -Dgemfire.EXPIRY_THREADS=10
    ...
System Properties:
    ...
    ...
    gemfire.EXPIRY_THREADS = 10
    ...

Upon checking the logs, there were occurrences only for <Expiry 9>, <Expiry 1>, <Expiry 4>, <Expiry 6> but not for all the 10 threads as I would have expected to see.

Is there a reliable way to verify from the GemFire server logs that the configured number of threads are being created/used for the expiration?

GemFire version: 9.10.13

pradhan
  • 1
  • 3

1 Answers1

0

The underlying ExecutorService, that is created when the EXPIRY_THREADS property is set and that handles expiration tasks, has a core (or minimum) pool size of 1. So it's quite likely that not all threads are being created as the expiry tasks execute quite quickly.

Since you're seeing logs with threads named as you mention, you can be sure that this ExecutorService has the configured maximum thread capability. Unfortunately there aren't any stats available for this particular aspect otherwise you could also use those to check.

Jens D
  • 4,229
  • 3
  • 16
  • 19