What causes this error:

StreamBaseException: java.lang.RuntimeException: Constant pool has grown past JVM limit of 0xFFFF

and how can we correct it?

An EventFlow element generates a class too large for Java and needs to be refactored.

The "Constant pool has grown past JVM limit of 0xFFFF" error means that the set of preserved string values in the class generated from a specific EventFlow element has grown too large for Java to preserve in the class's bytecode structure. This limit is rarely reached since most strings are removed as most names are not important at runtime. However, running in debug mode preserves strings so the debugger can name what is shown which can trigger this error.

That error is closely related to errors like this:

Error: SyntaxError Evaluation exception: Compiling "RuntimeExpr_15...": Code of method "eval(Lcom/streambase/sb/dataclass/activevoice/DataClassBase;)Z" 
of class "runtime.RuntimeExpr_15..." grows beyond 64 KB: Runtime exception

and the solutions are the same.

Wide and deep schemas (many levels of nested tuples, or 100's of fields at any level) will use Constant Pool memory for the element processing the tuple with that schema.

Check for recent additions to expressions in Map, Aggregate, Query, and other operators that can take complex output expressions. Check for long string constant values in EventFlow elements, or reference data pre-loaded into Query Tables. See if these strings can be loaded from a file at startup instead of being included explicitly in the element (for example, a US Area Code lookup table). Also, check the values of Constants and Parameters provided from configuration. If the same information can be provided at startup by reading a CSV file, this will allow these strings to occupy Heap Memory instead of class Constant Pool space.

The operator causing the problem can be found by selectively disabling portions of the application and seeing whether the issue is repeated or not at application startup. Of course, when performing this test the application is not expected to be functional. The test is only to make sure the application can make it through the startup compilation phase before the server reports "Listening" and allowing tuples to flow.

Once the problem element is found, the solution is to split the work it does into two or more operators that are individually smaller. Typically each element compiles to a Java class. This would split the work into two classes, avoiding the error by storing fewer constant elements in each class. If the cause is a large schema, then reducing the number of fields in the schema will be needed, but this should be considered only if the work cannot be split.