Chapter 8. Postinstallation Configuration

Current implementation of Java Virtual Machine allows only a global configuration of memory for the JVM system process. Thus the whole application server, together with WARs and EARs running on it, share one memory space.

Default JVM memory settings is too low for running an application container with CloverDX Server. Some application servers, like IBM WebSphere, increase JVM defaults themselves, however they still may be too low.

The optimal memory limits depend on many conditions, i.e. transformations which CloverDX should execute. Please note that the maximum limit isn't the amount of permanently allocated memory, but limit which can't be exceeded. If the limit is exhausted, the OutOfMemoryError is raised.

-XX:ReservedCodeCacheSize=256m

When using resource-demanding components, such as FastSort, or when running a large number of graphs concurrently, you may reach the system limit on simultaneously open files. This is usually indicated by the java.io.IOException: Too many open files exception.

The default limit is fairly low in many Linux distributions (e.g. 4,096 in Ubuntu). Such a limit can be easily exceeded, considering that one FastSort component can open up to 1,000 files when sorting 10 million records. Furthermore, some application containers recommend increasing the limit themselves (8,192 for IBM WebSphere).

Therefore, it is recommended to increase the limit for production systems. Reasonable limits vary from 10,000 to about 100,000 depending on the expected load of CloverDX Server and the complexity of your graphs.

The current limit can be displayed in most UNIX-like systems using the ulimit -Sn command.

The exact way of increasing the limit is OS-specific and is beyond the scope of this manual.

If you run graphs with many subgraphs containing many components, you may reach the limit on number of threads per user or per system. In this case, you can find java.lang.OutOfMemoryError: unable to create new native thread in a graph's log.

The current limit on number of processes/threads per user can be displayed in most UNIX-like systems using the ulimit -Su command. Note that the documentation on ulimit may not distinguish between processes and threads. The limit on number of threads per system can be displayed using the sysctl kernel.threads-max command. The exact way of increasing the limit is OS-specific and is beyond the scope of this manual.

In order to function properly, CloverDX Server requires an outside communication. The table below describes both incoming and outgoing communication of CloverDX Server. Please, configure your firewall exceptions accordingly.

We recommend using the G1 garbage collector for Worker, as it behaves better on huge heaps and causes shorter full stops of the Java Virtual Machine. G1 is the default garbage collector in Java 9 or newer; however, for Java 8 the Parallel garbage collector is the default and G1 is just optional. Because of that, CloverDX automatically enables G1 garbage collector for Worker on Java 8.

If worker.javaExecutable is not specified and no specific garbage collector is selected by the worker.jvmOptions property, CloverDX uses the G1 garbage collector on Worker by default on Java 8. So if you modify the JVM used by Worker, we don't set G1 by default. Also, if you specify a different garbage collector, we don't override this setting.

CloverDX Server instance can run behind a HTTP proxy that provides services such as logging, SSL termination, caching, load balancing, access control, etc. However, the proxy may break some parts of the CloverDX Sever console. For instance, the endpoint URL for Data Services will not show the public URL used in the web browser, but the internal URL of CloverDX Server instance, as seen by the proxy. That is because the Data Service endpoint URL is constructed from the incoming request and the request no longer comes from the client, but from the proxy.

As a workaround, you may configure the proxy to override the URL using the following HTTP headers:

The following snippets show configuration examples for commonly used proxy servers.

# Requires mod_proxy module
<Location "/mycontext">
    # Enable proxy
    ProxyPass "http://cloverdx-svc:8080/clover"
    # Pass "Host" header value; alternatively, set X-Forwarded-Host
    ProxyPreserveHost On
    # Fix "Location" response headers in redirects
    ProxyPassReverse "http://cloverdx-svc:8080/clover"

    # Add "X-Forwarded-Proto" header when running as a SSL terminator
    #RequestHeader set X-Forwarded-Proto "https"

    ### Only necessary when changing the context path from "/clover" to something else:
    # Add "X-Forwarded-Prefix" header to override the context path
    RequestHeader set X-Forwarded-Prefix "/mycontext"
    # Fix path in "Set-Cookie" headers
    ProxyPassReverseCookiePath "/clover" "/mycontext"
</Location>

events {
}

http {

  server { # simple reverse-proxy
    listen       80;

    location /mycontext {
        # Enable proxy
        proxy_pass          http://cloverdx-svc:8080/clover;
        # Pass "Host" header value; alternatively, set X-Forwarded-Host
        proxy_set_header    Host $http_host;
        # Fix "Location" response headers in redirects
        proxy_redirect      http://$http_host/clover http://$http_host/mycontext;

        # Add "X-Forwarded-Proto" header when running as a SSL terminator
        #proxy_set_header   X-Forwarded-Proto https

        ### Only necessary when changing the context path from "/clover" to something else:
        # Override context path
        proxy_set_header    X-Forwarded-Prefix /mycontext;
        # Fix path in "Set-Cookie" headers
        proxy_cookie_path   /clover /mycontext;
    }

  }

}