Pentaho Home

Mondrian Documentation

Configuration Guide


  1. Properties
    1. Property list
  2. Connect strings
    1. Syntax
    2. Connect string properties
  3. Cache management
    1. Schema cache
  4. Memory management
    1. Out of memory
  5. Logging
    1. Configuring log4j within Mondrian's test environment
    2. MDX and SQL Statement Logging

1. Properties 

Mondrian has a properties file to allow you to configure how it executes. The file is loaded when the executing Mondrian JAR detects it needs properties, but can also be done explicitly in your code. It looks in several places, in the following order:

  1. In the directory where you started your JVM (Current working directory for JVM process, java.exe on Win32, java on UNIX/Linux).
  2. If there isn't under current working directory of JVM process, Class MondrianProperties's classloader will try to locate in all of its classpaths. So you may put under /WEB-INF/classes when you pack Mondrian into a Java web application. The demonstration web applications have this configuration.

These properties are stored as system properties, so they can be set during JVM startup via -D<property>=<value>.

1.1 Property list 

The following properties in effect the operations of Mondrian.

Not all of the properties in this table are of interest to the end-user. For example, those in the 'Testing' are only applicable if are running Mondrian's suite of regression tests.

Property Type Default value Description

Aggregate tables
mondrian­.­rolap­.­aggregates­.­rule­.­tag string default

String property that is the AggRule element's tag value­.­

Normally­,­ this property is not set by a user­.­

mondrian­.­rolap­.­aggregates­.­rules string ­/­DefaultRules­.­xml

String property containing the name of the file which defines the rules for recognizing an aggregate table­.­ Can be either a resource in the Mondrian jar or a URL­.­

The default value is "/DefaultRules­.­xml"­,­ which is in the mondrian­.­rolap­.­aggmatcher package in Mondrian­.­jar­.­

Normally­,­ this property is not set by a user­.­

mondrian­.­rolap­.­aggregates­.­ChooseByVolume boolean false

Boolean property that controls whether aggregate tables are ordered by their volume or row count­.­

If true­,­ Mondrian uses the aggregate table with the smallest volume (number of rows multiplied by number of columns)­;­ if false­,­ Mondrian uses the aggregate table with the fewest rows­.­

mondrian­.­rolap­.­aggregates­.­generateSql boolean false

Boolean property that controls whether to print the SQL code generated for aggregate tables­.­

If set­,­ then as each aggregate request is processed­,­ both the lost and collapsed dimension create and insert sql code is printed­.­ This is for use in the CmdRunner allowing one to create aggregate table generation sql­.­

mondrian­.­rolap­.­aggregates­.­jdbcFactoryClass string -

Property that defines the JdbcSchema factory class which determines the list of tables and columns of a specific datasource­.­

@see mondrian­.­rolap­.­aggmatcher­.­JdbcSchema
mondrian­.­rolap­.­aggregates­.­optimizePredicates boolean true

Boolean property that determines whether Mondrian optimizes predicates­.­

If true­,­ Mondrian may retrieve a little more data than specified in MDX query and cache it for future use­.­ For example­,­ if you ask for data on 48 states of the United States for 3 quarters of 2011­,­ Mondrian will round out to all 50 states and all 4 quarters­.­ If false­,­ Mondrian still optimizes queries that involve all members of a dimension­.­

mondrian­.­rolap­.­aggregates­.­Read boolean false

Boolean property that determines whether Mondrian should read aggregate tables­.­

If set to true­,­ then Mondrian scans the database for aggregate tables­.­ Unless mondrian­.­rolap­.­aggregates­.­Use is set to true­,­ the aggregates found will not be used­.­

mondrian­.­rolap­.­aggregates­.­Use boolean false

Boolean property that controls whether Mondrian uses aggregate tables­.­

If true­,­ then Mondrian uses aggregate tables­.­ This property is queried prior to each aggregate query so that changing the value of this property dynamically (not just at startup) is meaningful­.­

Aggregates can be read from the database using the {@link #ReadAggregates} property but will not be used unless this property is set to true­.­

mondrian­.­rolap­.­star­.­disableCaching boolean false Boolean property that controls whether a RolapStar's aggregate data cache is cleared after each query­.­ If true­,­ no RolapStar will cache aggregate data from one query to the next (the cache is cleared after each query)­.­
mondrian­.­rolap­.­star­.­disableLocalSegmentCache boolean false Boolean property that controls whether the data from segments is cached locally­.­ To create custom caches­,­ look for the SegmentCache SPI­.­
mondrian­.­expCache­.­enable boolean true Boolean property that controls whether to use a cache for frequently evaluated expressions­.­ With the cache disabled­,­ an expression like Rank([Product]­.­CurrentMember­,­ Order([Product]­.­MEMBERS­,­ [Measures]­.­[Unit Sales])) would perform many redundant sorts­.­ The default is true­.­
mondrian­.­rolap­.­EnableRolapCubeMemberCache boolean true

Property that determines whether to cache RolapCubeMember objects­,­ each of which associates a member of a shared hierarchy with a particular cube in which it is being used­.­

The default is {@code true}­,­ that is­,­ use a cache­.­ If you wish to use the member cache control aspects of {@link mondrian­.­olap­.­CacheControl}­,­ you must set this property to {@code false}­.­

RolapCubeMember has recently become more lightweight to construct­,­ and we may obsolete this cache and this property­.­

mondrian­.­spi­.­dataSourceResolverClass string -

Property that defines the name of the plugin class that resolves data source names to {@link javax­.­sql­.­DataSource} objects­.­ The class must implement the {@link mondrian­.­spi­.­DataSourceResolver} interface­.­ If not specified­,­ the default implementation uses JNDI to perform resolution­.­


mondrian­.­calc­.­ExpCompiler­.­class string -

Property that defines the name of the class used to compile scalar expressions­.­

If the value is non-null­,­ it is used by the ExpCompiler­.­Factory to create the implementation­.­

To test that for all test MDX queries that all functions can handle requests for ITERABLE­,­ LIST and MUTABLE_LIST evaluation results­,­ use the following:

mondrian­.­util­.­MemoryMonitor­.­class string -

Property that defines the name of the class used as a memory monitor­.­

If the value is non-null­,­ it is used by the MemoryMonitorFactory to create the implementation­.­

mondrian­.­rolap­.­RolapMember­.­PropertyValueMapFactory­.­class string -

Property that defines the name of the factory class used to create maps of member properties to their respective values­.­

If the value is non-null­,­ it is used by the PropertyValueFactory to create the implementation­.­ If unset­,­ {@link mondrian­.­rolap­.­RolapMemberBase­.­DefaultPropertyValueMapFactory} will be used­.­

mondrian­.­rolap­.­SqlMemberSource­.­ValuePoolFactory­.­class string -

Property that defines the name of the class used in SqlMemberSource to pool common values­.­

If the value is non-null­,­ it is used by the SqlMemberSource­.­ValueMapFactory to create the implementation­.­ If it is not set­,­ then {@link mondrian­.­rolap­.­SqlMemberSource­.­NullValuePoolFactory} will be used­,­ meaning common values will not be pooled­.­

mondrian­.­olap­.­case­.­sensitive boolean false Boolean property that controls whether the MDX parser resolves uses case-sensitive matching when looking up identifiers­.­ The default is false­.­
mondrian­.­rolap­.­cellBatchSize int -1 Integer property that­,­ if set to a value greater than zero­,­ sets a hard limit on the number of cells that are batched together when building segments­.­
mondrian­.­rolap­.­compareSiblingsByOrderKey boolean false Boolean property that controls whether sibling members are compared according to order key value fetched from their ordinal expression­.­ The default is false (only database ORDER BY is used)­.­
mondrian­.­olap­.­fun­.­crossjoin­.­optimizer­.­size int 0

Property that defines when to apply the crossjoin optimization algorithm­.­

If a crossjoin input list's size is larger than this property's value and the axis has the "NON EMPTY" qualifier­,­ then the crossjoin non-empty optimizer is applied­.­ Setting this value to '0' means that for all crossjoin input lists in non-empty axes will have the optimizer applied­.­ On the other hand­,­ if the value is set larger than any possible list­,­ say Integer­.­MAX_VALUE­,­ then the optimizer will never be applied­.­

mondrian­.­rolap­.­agg­.­enableCacheHitCounters boolean false

Property that controls whether aggregation cache hit / miss counters will be enabled­.­

Note that this will affect performance due to existence of sync blocks­.­

@deprecated This property is no longer used­,­ and will be removed in mondrian-4­.­0­.­
mondrian­.­drillthrough­.­enable boolean true If disabled­,­ Mondrian will throw an exception if someone attempts to perform a drillthrough of any kind­.­
mondrian­.­rolap­.­EnableInMemoryRollup boolean true Property which turns on or off the in-memory rollup of segment data­.­ Defaults to true­.­
mondrian­.­rolap­.­nonempty boolean false Boolean property that controls whether each query axis implicit has the NON EMPTY option set­.­ The default is false­.­
mondrian­.­olap­.­triggers­.­enable boolean true

Boolean property that controls whether to notify the Mondrian system when a {@link MondrianProperties property value} changes­.­

This allows objects dependent on Mondrian properties to react (that is­,­ reload)­,­ when a given property changes via­,­ say­,­ MondrianProperties­.­instance()­.­populate(null) or MondrianProperties­.­instance()­.­QueryLimit­.­set(50)­.­

mondrian­.­result­.­highCardChunkSize int 1 Property that establishes the amount of chunks for querying cells involving high-cardinality dimensions­.­ Should prime with {@link #ResultLimit mondrian­.­result­.­limit}­.­
mondrian­.­rolap­.­ignoreInvalidMembers boolean false

Property that defines whether non-existent member errors should be ignored during schema load­.­ If so­,­ the non-existent member is treated as a null member­.­

mondrian­.­rolap­.­ignoreInvalidMembersDuringQuery boolean false

Property that defines whether non-existent member errors should be ignored during query validation­.­ If so­,­ the non-existent member is treated as a null member­.­

mondrian­.­olap­.­agg­.­IgnoreMeasureForNonJoiningDimension boolean false

Property that defines whether to ignore measure when non joining dimension is in the tuple during aggregation­.­

If there are unrelated dimensions to a measure in context during aggregation­,­ the measure is ignored in the evaluation context­.­ This behaviour kicks in only if the CubeUsage for this measure has IgnoreUnrelatedDimensions attribute set to false­.­

For example­,­ Gender doesn't join with [Warehouse Sales] measure­.­

With mondrian­.­olap­.­agg­.­IgnoreMeasureForNonJoiningDimension­=­true Warehouse Sales gets eliminated and is ignored in the aggregate value­.­

[Store Sales] + [Warehouse Sales] SUM({Product­.­members * Gender­.­members}) 7­,­913­,­333­.­82

With mondrian­.­olap­.­agg­.­IgnoreMeasureForNonJoiningDimension­=­false Warehouse Sales with Gender All level member contributes to the aggregate value­.­

[Store Sales] + [Warehouse Sales] SUM({Product­.­members * Gender­.­members}) 9­,­290­,­730­.­03

On a report where Gender M­,­ F and All members exist a user will see a large aggregated value compared to the aggregated value that can be arrived at by summing up values against Gender M and F­.­ This can be confusing to the user­.­ This feature can be used to eliminate such a situation­.­

mondrian­.­rolap­.­iterationLimit int 0

Integer property indicating the maximum number of iterations allowed when iterating over members to compute aggregates­.­ A value of 0 (the default) indicates no limit­.­

mondrian­.­jdbcDrivers string sun­.­jdbc­.­odbc­.­JdbcOdbcDriver­,­org­.­hsqldb­.­jdbcDriver­,­oracle­.­jdbc­.­OracleDriver­,­com­.­mysql­.­jdbc­.­Driver Property containing a list of JDBC drivers to load automatically­.­ Must be a comma-separated list of class names­,­ and the classes must be on the class path­.­
mondrian­.­rolap­.­localePropFile string -

String property that holds the name of the class whose resource bundle is to be used to for this schema­.­ For example­,­ if the class is {@code com­.­acme­.­MyResource}­,­ mondrian will look for a resource bundle called {@code com/acme/MyResource_locale­.­properties} on the class path­.­ (This property has a confusing name because in a previous release it actually held a file name­.­)

Used for the {@link mondrian­.­i18n­.­LocalizingDynamicSchemaProcessor}­;­ see Internationalization for more details­.­

Default value is null­.­

log4j­.­configuration string -

Set mondrian logging information if not provided by containing application­.­



mondrian­.­rolap­.­evaluate­.­MaxEvalDepth int 10

Boolean property that defines the maximum number of passes allowable while evaluating an MDX expression­.­

If evaluation exceeds this depth (for example­,­ while evaluating a very complex calculated member)­,­ Mondrian will throw an error­.­

mondrian­.­native­.­NativizeMaxResults int 150­,­000

Property that controls the maximum number of results contained in a NativizeSet result set­.­

If the number of tuples contained in the result set exceeds this value Mondrian throws a LimitExceededDuringCrossjoin error­.­

mondrian­.­native­.­NativizeMinThreshold int 100­,­000

Property that controls minimum expected cardinality required in order for NativizeSet to natively evaluate a query­.­

If the expected cardinality falls below this level the query is executed non-natively­.­

It is possible for the actual cardinality to fall below this threshold even though the expected cardinality falls above this threshold­.­ In this case the query will be natively evaluated­.­

mondrian­.­olap­.­elements­.­NeedDimensionPrefix boolean false

Property determines if elements of dimension (levels­,­ hierarchies­,­ members) need to be prefixed with dimension name in MDX query­.­

For example when the property is true­,­ the following queries will error out­.­ The same queries will work when this property is set to false­.­

select {[M]} on 0 from sales

select {[USA]} on 0 from sales

select {[USA]­.­[CA]­.­[Santa Monica]} on 0 from sales

When the property is set to true­,­ any query where elements are prefixed with dimension name as below will work

select {[Gender]­.­[F]} on 0 from sales

select {[Customers]­.­[Santa Monica]} on 0 from sales

Please note that this property does not govern the behaviour wherein


is resolved into a fully qualified


In a scenario where the schema is very large and dimensions have large number of members a MDX query that has a invalid member in it will cause mondrian to to go through all the dimensions­,­ levels­,­ hierarchies­,­ members and properties trying to resolve the element name­.­ This behavior consumes considerable time and resources on the server­.­ Setting this property to true will make it fail fast in a scenario where it is desirable­.­

mondrian­.­olap­.­NullDenominatorProducesNull boolean false

Property that defines the behavior of division if the denominator evaluates to zero­.­

If false (the default)­,­ if a division has a non-null numerator and a null denominator­,­ it evaluates to "Infinity"­,­ which conforms to SSAS behavior­.­

If true­,­ the result is null if the denominator is null­.­ Setting to true enables the old semantics of evaluating this to null­;­ this does not conform to SSAS­,­ but is useful in some applications­.­

mondrian­.­olap­.­NullMemberRepresentation string #null

Property that determines how a null member value is represented in the result output­.­

AS 2000 shows this as empty value

AS 2005 shows this as "(null)" value

mondrian­.­query­.­limit int 40

Maximum number of simultaneous queries the system will allow­.­

Oracle fails if you try to run more than the 'processes' parameter in init­.­ora­,­ typically 150­.­ The throughput of Oracle and other databases will probably reduce long before you get to their limit­.­

mondrian­.­rolap­.­queryTimeout int 0

Property that defines the timeout value (in seconds) for queries­.­ A value of 0 (the default) indicates no timeout­.­

mondrian­.­result­.­limit int 0 Integer property that­,­ if set to a value greater than zero­,­ limits the maximum size of a result set­.­
mondrian­.­rolap­.­maxQueryThreads int 10

Maximum number of MDX query threads per Mondrian server instance­.­ Defaults to 10­.­

mondrian­.­rolap­.­shepherdThreadPollingInterval string 1000ms

Property that defines the interval value between polling operations performed by the RolapConnection shepherd thread­.­ This controls query timeouts and cancellation­,­ so a small value (a few milliseconds) is best­.­ Setting this to a value higher than mondrian­.­rolap­.­queryTimeout will result the timeout not being enforced as expected­.­

Default value is "1000ms"­.­ Default time unit is "ms"­.­

mondrian­.­rolap­.­SegmentCache string - Property which defines which SegmentCache implementation to use­.­ Specify the value as a fully qualified class name­,­ such as org­.­example­.­SegmentCacheImpl where SegmentCacheImpl is an implementation of {@link mondrian­.­spi­.­SegmentCache}­.­
mondrian­.­rolap­.­maxCacheThreads int 100

Maximum number of threads per Mondrian server instance that are used to run perform operations on the external caches­.­ Defaults to 100­.­

mondrian­.­rolap­.­maxSqlThreads int 100

Maximum number of threads per Mondrian server instance that are used to run SQL queries when populating segments­.­ Defaults to 100­.­

mondrian­.­rolap­.­SolveOrderMode string ABSOLUTE Property that controls the behavior of {@link Property#SOLVE_ORDER solve order} of calculated members and sets­.­

Valid values are "absolute" and "scoped" (the default)­.­ See {@link mondrian­.­olap­.­SolveOrderMode} for details­.­

mondrian­.­rolap­.­SparseSegmentValueThreshold int 1­,­000

Property that­,­ with {@link #SparseSegmentDensityThreshold}­,­ determines whether to choose a sparse or dense representation when storing collections of cell values in memory­.­

When storing collections of cell values­,­ Mondrian has to choose between a sparse and a dense representation­,­ based upon the possible and actual number of values­.­ The density is actual / possible­.­

We use a sparse representation if (possible - {@link #SparseSegmentCountThreshold countThreshold}) * {@link #SparseSegmentDensityThreshold densityThreshold} >­;­ actual

For example­,­ at the default values ({@link #SparseSegmentCountThreshold countThreshold} ­=­ 1000­,­ {@link #SparseSegmentDensityThreshold} ­=­ 0­.­5)­,­ we use a dense representation for

  • (1000 possible­,­ 0 actual)­,­ or
  • (2000 possible­,­ 500 actual)­,­ or
  • (3000 possible­,­ 1000 actual)­.­

Any fewer actual values­,­ or any more possible values­,­ and Mondrian will use a sparse representation­.­

mondrian­.­rolap­.­SparseSegmentDensityThreshold double 0­.­5 Property that­,­ with {@link #SparseSegmentCountThreshold}­,­ determines whether to choose a sparse or dense representation when storing collections of cell values in memory­.­
mondrian­.­olap­.­SsasCompatibleNaming boolean false

Property that defines whether to enable new naming behavior­.­

If true­,­ hierarchies are named [Dimension]­.­[Hierarchy]­;­ if false­,­ [Dimension­.­Hierarchy]­.­

mondrian­.­statistics­.­providers string -

Comma-separated list of classes to be used to get statistics about the number of rows in a table­,­ or the number of distinct values in a column­.­

If there is a value for mondrian­.­statistics­.­providers­.­DATABASE­,­ where DAtABASE is the current database name (e­.­g­.­ MYSQL or ORACLE)­,­ then that property overrides­.­




This would use JDBC's statistics (via the java­.­sql­.­DatabaseMetaData­.­getIndexInfo method) for most databases­,­ but for connections to a MySQL database­,­ would use external statistics first­,­ and fall back to JDBC statistics only if external statistics were not available­.­

mondrian­.­test­.­highCardDimensions string - Property containing a list of dimensions in the Sales cube that should be treated as high-cardinality dimensions by the testing infrastructure­.­ This allows us to run the full suite of tests with high-cardinality functionality enabled­.­
mondrian­.­webapp­.­connectString string Provider­=­mondrian­;­Jdbc­=­jdbc:odbc:MondrianFoodMart­;­Catalog­=­­/­WEB-INF­/­queries­/­FoodMart­.­xml­;­JdbcDrivers­=­sun­.­jdbc­.­odbc­.­JdbcOdbcDriver

Connect string for the webapp­.­ (Used by the webapp only­.­)

To achieve access control­,­ append say ­;­Role­=­'California manager' to the connect string­.­

mondrian­.­webapp­.­deploy string -

Where mondrian­.­war will be deployed to­.­ (Used by mondrian's build­.­xml ant file only­.­)

Example: mondrian­.­webapp­.­deploy­=­C:/jboss-4­.­0­.­2/server/default/deploy

mondrian­.­xmla­.­SchemaRefreshInterval string 3000ms

Interval at which to refresh the list of XML/A catalogs­.­ (Usually known as the datasources­.­xml file­.­)

It is not an active process­;­ no threads will be created­.­ It only serves as a rate limiter­.­ The refresh process is triggered by requests to the doPost() servlet method­.­

Values may have time unit suffixes such as 's' (second) or 'ms' (milliseconds)­.­ Default value is 3000 milliseconds (3 seconds)­.­ Default time unit is milliseconds­.­

See also {@link mondrian­.­xmla­.­impl­.­DynamicDatasourceXmlaServlet}­.­

mondrian­.­server­.­monitor­.­executionHistorySize int 1­,­000

Property that defines how many previous execution instances the Monitor keeps in its history so that it can send the events which happen after the fact­.­ Setting this property too high will make the JVM run out of memory­.­ Setting it too low might prevent some events from reaching the listeners of the monitor­.­

This property is for internal use only and should not be changed unless required­.­ Defaults to 1­,­000­.­

mondrian­.­util­.­memoryMonitor­.­enable boolean false

Property that defines whether the MemoryMonitor should be enabled­.­ By default it is disabled­;­ memory monitor is not available before Java version 1­.­5­.­

mondrian­.­util­.­memoryMonitor­.­percentage­.­threshold int 90

Property that defines the default MemoryMonitor percentage threshold­.­ If enabled­,­ when Java's memory monitor detects that post-garbage collection is above this value­,­ notifications are generated­.­

SQL generation
mondrian­.­native­.­unsupported­.­alert string OFF

Alerting action to take in case native evaluation of a function is enabled but not supported for that function's usage in a particular query­.­ (No alert is ever raised in cases where native evaluation would definitely have been wasted effort­.­)

Recognized actions:

  • OFF: do nothing (default action­,­ also used if unrecognized action is specified)
  • WARN: log a warning to RolapUtil logger
  • ERROR: throw an instance of {@link NativeEvaluationUnsupportedException}
mondrian­.­rolap­.­groupingsets­.­enable boolean false

Property that defines whether to generate SQL queries using the GROUPING SETS construct for rollup­.­ By default it is not enabled­.­

Ignored on databases which do not support the GROUPING SETS construct (see {@link mondrian­.­spi­.­Dialect#supportsGroupingSets})­.­

mondrian­.­native­.­crossjoin­.­enable boolean true If enabled some NON EMPTY CrossJoin will be computed in SQL­.­
mondrian­.­native­.­filter­.­enable boolean true If enabled some Filter() will be computed in SQL­.­
mondrian­.­native­.­nonempty­.­enable boolean true

If enabled some NON EMPTY set operations like member­.­children­,­ level­.­members and member descendants will be computed in SQL­.­

mondrian­.­native­.­topcount­.­enable boolean true If enabled some TopCount will be computed in SQL­.­
mondrian­.­native­.­ExpandNonNative boolean false If this property is true­,­ when looking for native evaluation of an expression­,­ Mondrian will expand non-native sub-expressions into lists of members­.­
mondrian­.­rolap­.­FilterChildlessSnowflakeMembers boolean true

Property that defines whether to generate joins to filter out members in a snowflake dimension that do not have any children­.­

If true (the default)­,­ some queries to query members of high levels snowflake dimensions will be more expensive­.­ If false­,­ and if there are rows in an outer snowflake table that are not referenced by a row in an inner snowflake table­,­ then some queries will return members that have no children­.­

Our recommendation­,­ for best performance­,­ is to remove rows outer snowflake tables are not referenced by any row in an inner snowflake table­,­ during your ETL process­,­ and to set this property to {@code false}­.­

mondrian­.­rolap­.­generate­.­formatted­.­sql boolean false

Boolean property that controls pretty-print mode­.­

If true­,­ the all SqlQuery SQL strings will be generated in pretty-print mode­,­ formatted for ease of reading­.­

mondrian­.­rolap­.­maxConstraints int 1­,­000

Max number of constraints in a single 'IN' SQL clause­.­

This value may be variant among database products and their runtime settings­.­ Oracle­,­ for example­,­ gives the error "ORA-01795: maximum number of expressions in a list is 1000"­.­

Recommended values:

  • Oracle: 1­,­000
  • DB2: 2­,­500
  • Other: 10­,­000

mondrian­.­catalogURL string - Property that contains the URL of the catalog to be used by {@link mondrian­.­tui­.­CmdRunner} and XML­/­A Test­.­
mondrian­.­foodmart­.­jdbcURL string jdbc:odbc:MondrianFoodMart

Property containing the JDBC URL of the FoodMart database­.­ The default value is to connect to an ODBC data source called "MondrianFoodMart"­.­

To run the test suite­,­ first load the FoodMart data set into the database of your choice­.­ Then set the driver­.­classpath­,­ mondrian­.­foodmart­.­jdbcURL and mondrian­.­jdbcDrivers properties­,­ by un-commenting and modifying one of the sections below­.­ Put the JDBC driver jar into mondrian/testlib­.­

Here are example property settings for various databases­.­

Derby: needs user and password










Greenplum (similar to Postgres)






LucidDB (see instructions)





Oracle (needs user and password)









ODBC (Microsoft Access)








MySQL: can have user and password set in JDBC URL








As MySQL­.­ (Infobright uses a MySQL driver­,­ version 5­.­1 and later­.­)





Postgres: needs user and password











Netezza: mimics Postgres





























mondrian­.­test­.­Iterations int 1 Not documented­.­
mondrian­.­test­.­QueryFileDirectory string - Property defining where the test XML files are­.­
mondrian­.­test­.­QueryFilePattern string - Property that defines a pattern for which test XML files to run­.­ Pattern has to match a file name of the form: querywhatever­.­xml in the directory­.­


mondrian­.­test­.­Class string -

String property that determines which test class to run­.­

This is the name of the class­.­ It must either implement {@code junit­.­framework­.­Test} or have a method {@code public [static] junit­.­framework­.­Test suite()}­.­


@see #TestName
mondrian­.­test­.­connectString string -

Property containing the connect string which regression tests should use to connect to the database­.­

Format is specified in {@link Util#parseConnectString(String)}­.­

mondrian­.­test­.­ExpDependencies int 0

Integer property that controls whether to test operators' dependencies­,­ and how much time to spend doing it­.­

If this property is positive­,­ Mondrian's test framework allocates an expression evaluator which evaluates each expression several times­,­ and makes sure that the results of the expression are independent of dimensions which the expression claims to be independent of­.­

The default is 0­.­

mondrian­.­foodmart­.­jdbcPassword string - Property containing the JDBC password of a test database­.­ The default value is null­,­ to cope with DBMSs that don't need this­.­
mondrian­.­foodmart­.­jdbcUser string - Property containing the JDBC user of a test database­.­ The default value is null­,­ to cope with DBMSs that don't need this­.­
mondrian­.­test­.­Name string -

String property that determines which tests are run­.­

This is a regular expression as defined by {@link java­.­util­.­regex­.­Pattern}­.­ If this property is specified­,­ only tests whose names match the pattern in its entirety will be run­.­

@see #TestClass
mondrian­.­test­.­random­.­seed int 1­,­234

Seed for random number generator used by some of the tests­.­

Any value besides 0 or -1 gives deterministic behavior­.­ The default value is 1234: most users should use this­.­ Setting the seed to a different value can increase coverage­,­ and therefore may uncover new bugs­.­

If you set the value to 0­,­ the system will generate its own pseudo-random seed­.­

If you set the value to -1­,­ Mondrian uses the next seed from an internal random-number generator­.­ This is a little more deterministic than setting the value to 0­.­

mondrian­.­test­.­TimeLimit int 0 Property that returns the time limit for the test run in seconds­.­ If the test is running after that time­,­ it is terminated­.­
mondrian­.­test­.­VUsers int 1 Not documented­.­
mondrian­.­test­.­Warmup boolean false Property that indicates whether this is a "warmup test"­.­
mondrian­.­test­.­WarnIfNoPatternForDialect string NONE

Property that controls whether warning messages should be printed if a SQL comparison test does not contain expected SQL statements for the specified dialect­.­ The tests are skipped if no expected SQL statements are found for the current dialect­.­

Possible values are the following:

  • "NONE": no warning (default)
  • "ANY": any dialect
  • "ACCESS"
  • "DERBY"
  • "MYSQL"
  • ­.­­.­­.­ and any Dialect enum in SqlPattern­.­Dialect

Specific tests can overwrite the default setting­.­ The priority is:

  • Settings besides "ANY" in mondrian­.­properties file
  • <­;­ Any setting in the test
  • <­;­ "ANY"

mondrian­.­xmla­.­drillthroughTotalCount­.­enable boolean true If enabled­,­ first row in the result of an XML­/­A drill-through request will be filled with the total count of rows in underlying database­.­
mondrian­.­xmla­.­drillthroughMaxRows int 1­,­000 Property that defines limit on the number of rows returned by XML­/­A drill through request­.­

Limit properties 

Properties mondrian.result.limit, mondrian.rolap.iterationLimit and mondrian.rolap.queryTimeout enforce runtime limits on the time or space required to execute a query. If any of these limits are exceeded, mondrian throws an exception which extends mondrian.olap.ResultLimitExceededException.

Connect strings 

Connect string syntax 

Mondrian connect strings are a connection of property/value pairs, of the form 'property=value;property=value;...'.

Values can be enclosed in single-quotes, which allows them to contain spaces and punctuation. See the the OLE DB connect string syntax specification.

The supported properties are described below.

Connect string properties 

Name Required? Description
Provider Yes

Must have the value "Mondrian".

Jdbc Exactly one

The URL of the JDBC database where the data is stored. You must specify either DataSource or Jdbc.


The name of a data source loaded via JNDI. The name must be a valid JNDI name, and the object referenced must implement the javax.sql.DataSource interface. You must specify either DataSource or Jdbc.

JdbcDrivers Yes

Comma-separated list of JDBC driver classes, for example,

JdbcUser No

The name of the user to log on to the JDBC database. (If your JDBC driver allows you to specify the user name in the JDBC URL, you don't need to set this property.)

JdbcPassword No

The name of the password to log on to the JDBC database. (If your JDBC driver allows you to specify the password in the JDBC URL, you don't need to set this property.)

Catalog Exactly one

The URL of the catalog, an XML file which describes the schema: cubes, hierarchies, and so forth. For example,


Catalogs are described in the Schema Guide. See also CatalogContent.


An XML string representing the schema: cubes, hierarchies, and so forth. For example,

CatalogContent=<Schema name="MySchema"><Cube name="Cube1"> ... </Schema>

Catalogs are described in the Schema Guide. See also Catalog.

CatalogName No

Not used. If, in future, Mondrian supports multiple catalogs, this property will specify which catalog to use. See also Catalog.

PoolNeeded No

Tells Mondrian whether to add a layer of connection pooling.

If the value "true" is specified, or no value is specified, Mondrian assumes that:

  • connections created via the Jdbc property are not pooled, and therefore need to be pooled;
  • connections created via the DataSource are already pooled.

If the value "false" is specified, Mondrian does not apply connection-pooling to any connection.

Role No

The name of the role to adopt for access-control purposes. If not specified, the connection uses a role which has access to every object in the schema.

This property can contain multiple role names separated by commas. If so, queries in the connection execute with the sum of the privileges of all of the rules; the effect is the same as running under a union role, defined using the <Union> element in the schema file.

If a role name contains a comma, escape the comma using an extra comma. For example, a connection created with

Role='Pacific region manager,Europe,, Middle East and Africa manager'

will execute with the combined privileges of the roles "Pacific region manager", and "Europe, Middle East and Africa manager".

jdbc.* No

Any property whose name begins with "jdbc." will be added to the JDBC connection properties, after removing this prefix. This allows you to specify connection properties without a URL.

For example, given the properties

jdbc.Timeout=50; jdbc.CacheSize=1m

Mondrian will create a JDBC connection using the properties {Timeout="50", CacheSize="1m"}.

UseContentChecksum No

Allows mondrian to work with dynamically changing schema. If this property is set to true and schema content has changed (previous checksum doesn't equal with current), schema would be reloaded. The default is false.

Could be used in combination with DynamicSchemaProcessor property.

UseSchemaPool No

Controls whether a new connection use a schema from the schema cache. If true, the default, a connection shares a schema definition (and hence also a cache of aggregate data retrieved by previous queries) with other connections which have a textually identical schema definition.

If false, the connection has a private schema definition and cache.

DynamicSchemaProcessor No

The name of a class which is called at runtime in order to modify the schema content. The class must implement the mondrian.spi.DynamicSchemaProcessor interface. For example,

DynamicSchemaProcessor = mondrian.i18n.LocalizingDynamicSchemaProcessor

uses the builtin schema processor class mondrian.i18n.LocalizingDynamicSchemaProcessor to replace variables in the schema file, according to resource files and the current locale (see the Locale property).

Locale No

The requested Locale for the current session. The locale determines the formatting of numbers and date/time values, and Mondrian's error messages.

Example values are "en" (English), "en_US" (United States English), "hu" (Hungarian). If Locale is not specified, then the name of system's default will be used, as per java.util.Locale#getDefault().

JdbcConnectionUuid No

A unique identifier for the connection. If this is set, Mondrian will look at this property and no other to determine whether two data sources should be considered the same. You must ensure that connections will only share a JdbcConnectionUuid if they point to the same database.

Connect string properties are also documented in the RolapConnectionProperties class.

Cache management

Schema cache

To flush all schema definitions, use the mondrian.olap.CacheControl.flushSchemaCache() method:

import mondrian.olap.*;

Connection connection;
CacheControl cacheControl = connection.getCacheControl(null);

The cache is only used when creating new connections; existing connections retain their schemas.

There are four connect string properties that control the use of the Schema cache: UseSchemaPool, UseContentChecksum, CatalogContent and DynamicSchemaProcessor.

The UseSchemaPool property controls whether or not the cache is used regardless of the values of any of the other properties. If UseSchemaPool is "false", then the cache is not used; each request for a new schema object creates a new one (entailing the re-parsing of the schema definition and re-scanning of the database for meta data and aggregate tables - very slow, and, in addition, there is no reuse of the in-memory aggregate cache).

Next, if UseContentChecksum is "true", then a check sum (MD5) is created from the schema definition content (not URL) and it is this check sum that is used as the key to lookup previously cached versions of the schema definition. If two schema definitions produce different check sums, then one can safely assume that they are different schemas (of course, it is possible that only a comment or some whitespace in the schema definition changed in which case the two schemas would actually be the same, but because their check sums are different, different schema objects are used). If UseContentChecksum is "false", then no check sum is created and used as the lookup key, rather, a combination of the connection attributes "catalogUrl", "connectionKey", "jdbcUser", "dataSourceStr" or "catalogUrl", "dataSource" are used to create the key.

If the CatalogContent is specified, then it is used as the schema definition content. If, in fact, it is specified, then the value of DynamicSchemaProcessor, if any, is ignored.

Finally, the DynamicSchemaProcessor connection string property is the class name of a class that implements the DynamicSchemaProcessor interface. If set, an instance of the class is created for each schema request and its "processSchema" method is called which returns the schema definition content.

Memory management

Out Of Memory

Java OutOfMemoryError errors have always been an issue with applications. When the JVM throws an Error as opposed to an Exception it is telling the application that its world has ended and it has no recourse but to die. Prior to Java5 there was not much one could do other than buy 64-bit machines with lots of RAM and hope for the best. For a multi-user, Mondrian environment with potentially very large data-sets and clients that can generate queries requesting arbitrarily large amounts of that data, this can be an issue. This is especially the case when Mondrian is being hosted on some corporate web-server; applications that kill web-servers are not looked upon favorably by IT.

With Java5 (and Java6, etc.) there is alternative. An application cay take advantage of a new feature in Java5 allowing the application to be notified when memory starts running low. This allows the application to take preemptive action prior to an OutOfMemoryError being generated by the Java runtime.

Mondrian takes advantage of this new feature. Rather than passing an OutOfMemoryError to its client, it will now stop processing the present query, free up data structures associated with the present query and return a MemoryLimitExceededException to the client. The MemoryLimitExceededException is one of Mondrian's ResultLimitExceededException which are used to communicate with clients that a limit has been exceeded, in this case, memory usage.

By default, for Mondrian running under Java5, this feature is enabled and the "safety limit" is set at 90 percent, when memory usage gets to with 90 percent of the maximum possible, the the processing of the current query is stopped and a MemoryLimitExceededException is return to the client. See the Memory monitoring properties above on this page for additional information.

Lastly, the gorilla in the closet. Java5 in its wisdom only allows for one memory threshold notification level to be registered with the JVM. What this means is if within the same JVM, some code registers one level, say, at 80% (here I use percentages for ease of presentation rather than number of bytes which is what the Java5 API actually supports) and some other code later on registers a level of 90%, then it is the 90% that the JVM knows about - it knows nothing of the previously registered 80%. What this means is that the code expecting to be notified when the memory level crosses 80%, won't be notified!

For many applications that don't share their JVM with other applications, this is not a problem, but for Mondrian is it potentially an issue. Mondrian can be running in a Webserver and Webservers can have more than one independent applications. Each such application can register a different memory threshold notification level. In general, application-containing applications such as web-servers or application-servers are a problem with the current Java5 memory threshold notification approach. At the current time, I do not know a way around this problem.


Mondrian uses log4j for all information and debug logging. When running within an application server, Mondrian's log4j configuration is determined by the server's or web application's log4j configuration. Please see log4j's documentation for a additional details.

Configuring log4j within Mondrian's test environment

When running outside an application server, log4j determines the location of the log4j.xml file via the log4j.configuration java system property. log4j treats this string as a URL, so to have it detect the log4j file on the file system, you must use the syntax "file:DIR/log4j.xml". Relative paths are acceptible, so if you have your log4j.xml file in the root directory of mondrian, "file:log4j.xml" will load the correct file. You may specify the log4j.configuration property in, because Mondrian's ant build file explicitly sets the property as a JVM system property when running JUnit tests.

MDX and SQL Statement Logging

The default log4j.xml file is configured so that a separate log file is created for both MDX and SQL statement logging. In the code, the MDX and SQL strings are logged at the debug level, so to disable them you can set the log level to INFO or any other level above debug. Statement logging occurs within the log4j categories "mondrian.mdx" and "mondrian.sql". These categories log the statements and how long they took to execute. The SQL log also records the number of results returned in the result set.

For example, to trace both MDX and SQL statements, create a file in the directory where you started mondrian with the following contents:

# Set root logger level to DEBUG and its only appender to MONDRIAN.
log4j.rootLogger=WARN, MONDRIAN

# MONDRIAN is set to be a ConsoleAppender.

# MONDRIAN uses PatternLayout.
log4j.appender.MONDRIAN.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

# Trace MDX and SQL statements
log4j.category.mondrian.mdx=DEBUG, MONDRIAN
log4j.category.mondrian.sql=DEBUG, MONDRIAN

Then mondrian with the argument on the Java command line.

Consider setting the property mondrian.rolap.generate.formatted.sql=true in to make the format more readable.

Author: Julian Hyde; last modified April, 2011.
Version: $Id$ (log)
Copyright (C) 2006-2011 Pentaho