Enterprise and JIRA Data Center

Dataplane was designed to work well with enterprise-sized installations of Jira Server, as well as with Atlassian's high-availability Jira Data Center solution.

For most large Jira installations, no special tuning is required. This pages describes some special topics that may be relevant to customers with large installations.

Clustered Dataplane Indexing

Dataplane maintains a real-time index of Jira issue data. This index is stored as a new set of tables in the same database as Jira itself, so no additional database setup is required.

When building the Dataplane index for the first time, or when incorporating incremental changes to the index, Dataplane runs a background indexer task to create these tables and add the appropriate changes to the index.

In a Jira Data Center installation, this indexing task is performed on only one cluster node at a time. On startup, Dataplane will automatically select a cluster node to perform the indexing tasks. As cluster nodes are brought up and down, the indexing task will be automatically handed off to another live node in the cluster. For this reason, the node on which you click the "Build Index" button in the UI may not necessarily be the node that performs the underlying indexing work.

For performance reasons, the initial Dataplane index build process cannot be handed off to another node, so if you are building the Dataplane index for the very first time (or if you are performing an upgrade that necessitates a Dataplane reindex), you must ensure that the node performing the indexing operation remains up for the duration of the indexing process. If the node goes down in the middle of the index, the indexing process must be started again. If you have any questions about how to determine which node is performing the indexing, please contact Arsenale Support.

Database Connection Pool Tuning

By default, Dataplane will use up to 8 concurrent database connections, or one third of the total Jira database connection pool, whichever value is larger. If you have not modified the default Jira database configuration of 20 database connections, Dataplane will likely be using up to 8 connections.

This allows Dataplane to use enough connections to support multiple concurrent report requests, but this limit also prevents Dataplane from starving the core Jira application of database connections for other opertaions.

The defaults should be sufficient for most systems, but if you see slow-loading reports when many users are accessing the system, or if you see messages similar to the following in the Jira log, you may wish to increase your connection limit:

Request for new database connection is likely to exceed maximum limit of <NUMBER> connections

You may also wish to consult Jira's own database connection pool monitor to see how many connections are being used by Jira and Dataplane together.

All of the database connections used by Dataplane are taken from the Jira database connection pool. To increase the number of database connections available to Jira, you will need to edit $JIRA_DATA/dbconfig.xml and follow Atlassian's guide for tuning database connections. A sufficient number of connections must also be made available by your database server.

If you want Dataplane to use more or fewer than the default fraction (one third) of the total Jira connection pool size, you can also directly tune the number of database connections used by Dataplane. To do this, configure the following JVM system parameter in your bin/setenv.sh:

-Dcom.arsenalesystems.dataplane.db.maxConnections=<NUMBER>

where <NUMBER> is the maximum number of database connections that Dataplane will attempt to use at a single time. All of these connections are used from within the standard Jira JDBC connection pool, so the Jira connection pool size must also be larger than the number you specify here.

If needed, you can also tune some other parameters related to Dataplane's acquisition of database connections. Once Dataplane has exceeded the maximum number of connections specified above, if a new connection is required, Dataplane will wait up to 60 seconds for an existing connection to become available. If no connections are made available during that time, Dataplane will abort the report and display an error message to the user.

The default value of 60 seconds should be acceptable for most users. Should you have a need to tune the connection wait times, you can also configure the following parameter in bin/setenv.sh. Note that the specified value may not be smaller than 10 seconds.

-Dcom.arsenalesystems.dataplane.db.maxConnectionWaitTime=<DELAY_IN_SECONDS>

Database Table Usage

Dataplane creates and manages tables containing an "art" prefix within the main Jira database. These tables are used to hold ephemeral Dataplane indexing data. Although these tables are required for Dataplane to generate reports, all of the tables below can be recreated and rebuilt from scratch using the "Build Index" function in the Dataplane Administration page. These tables are not included during a standard Jira export/backup to XML, so it is necessary to rebuild the Dataplane index after doing an XML system restore.

The names of the ephemeral tables used by Dataplane are:

• artdate
• arthash
• artrid
• artstate
• artstatecf
• artstatecfdata
• artstatecfid
• artstatemap
• artstateprocessed
• artstateproperty
• arttdbl
• arttdt
• arttm

Additionally, Dataplane uses ActiveObjects-based tables to store permanent data related to saved reports and application configuration. All ActiveObjects-based tables begin with the prefix AO_6714C7. Data stored within the following tables must be preserved for correct product operation. These tables are automatically exported during a standard Jira backup/export to XML.

• AO_6714C7_CUSTOMIZER_GROUP
• AO_6714C7_PERMITTED_GROUP
• AO_6714C7_RECENT_REPORT_RECORD
• AO_6714C7_REPORTCOLLECTION
• AO_6714C7_REPORTCOLLECTIONLINK
• AO_6714C7_REPORT_SCHEDULE
• AO_6714C7_REPORT_SUBSCRIBER
• AO_6714C7_SAVED_REPORT_PERM
• AO_6714C7_SAVED_REPORT_RECORD