External Process Pool for Confluence Data Center

Still need help?

The Atlassian Community is here for you.

Ask the community

In Confluence Data Center we minimize the impact of particularly memory or CPU intensive actions by handling them in an external process pool, which is a seperate pool of processes, managed by Confluence. These processes (also known as sandboxes) can crash or be terminated, and will be restarted automatically by Confluence, without affecting the Confluence application itself.  

On this page:

The external process pool currently handles the following actions:

The external process pool is only available for Confluence Data Center.

In Confluence Server, these actions are handled by Confluence, so the information on this page does not apply. 

Memory requirements

You will need to make sure that Confluence has enough memory for the external process pool. In a clustered Data Center installation, you'll need to do this for each cluster node. The pool contains two processes (sandboxes) by default, so we recommend allowing an additional 2 GB on top of what is already required for Confluence (1 GB per sandbox). 

If you increase the size of the external process pool, make sure each node has enough free memory to cater for the extra processes. 

Configure the external process pool

In most cases the default values will be adequate, however system administrators can configure the external process pool using system properties. For example you may want to increase the size of the pool (the number of processes available), or increase the amount of memory a process can consume. Here are the main properties you may need to change:

  • conversion.sandbox.pool.size 
    Use this property to increase the number of processes (sandboxes) in the pool. You'll need to allow additional memory on each node for each additional process. 
  • conversion.sandbox.memory.limit.megabytes 
    Use this property to limit the amount of memory each process (sandbox) in the pool can consume. 

See Recognized System Properties for a full description of these properties, including additional properties that can be used to fine-tune, or disable sandboxes for particular actions. 

Monitor failed actions

When an external process (sandbox) is terminated, we'll write the following to the application log on that node:

2018-04-09 17:35:35 WARN [sandbox-terminator] 
[impl.util.sandbox.DefaultSandbox] lambda$startTerminator$0 Request 
has taken 33384ms exceeds limit 30000ms terminating sandbox

This will be followed by an Attempting to restart the sandbox message, the next time someone performs an action that uses the external process pool. 

Note that the process is not immediatley restarted after termination, as we don't re-attempt failed actions. We wait for the next request to spin up a new sandbox process. 

Last modified on Oct 11, 2021

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.