You are viewing documentation for Structure Server and Data Center version 5.4 and patch releases. For other versions, see Version Index or [Structure Cloud].
25th of October, 2018
Structure 5.1 adds wiki markup, an admin interface for dark features and several performance improvements and fixes.
Download the latest version of Structure and its Extensions
Try It: Structure Sandbox Server (no installation required)
Data Center customers: Due to a problem in the Atlassian Universal Plugin Manager, the previous Data Center approved version of Structure, Structure 5.0.1, was reported as incompatible. This problem does not occur with Structure 5.1.
Wiki markup is now supported within Formula columns.
Using wiki markup, you can:
Markup content can be included when exporting a structure to Excel or a printable page.
To learn more, see Wiki Markup in Formula Columns.
When grouping by Assignee (either through automation or transformation), the "Inactive" identifier is now visible beside the group name:
It is now possible to easily enable or disable dark features directly from a new Structure dark features interface.
To access the interface, you must have Jira Administration permissions and enter the interface location directly into your browser: https://YOUR_JIRA_ADDRESS/secure/admin/StructureDarkFeatures.jspa
Notes
Properties added with our admin interface are added to Application properties
A Structure property gets its value from Application properties; if no value is found, the property gets its value from System properties
For more information, see Advanced Configuration.
Structure 5.1 and all extensions support Jira versions from 7.2 or later. All editions of Jira (Jira Core, Jira Software, Jira Service Desk) are supported. Jira Data Center is supported.
With respect to other add-ons and custom integrations, this release is backwards-compatible with Structure 3.4–5.0. Structure.Testy extension, Colors , Structure.Pages, Structure.Gantt and integrations with third-party apps should continue working normally.
Structure 5.1 will be the last version to support Jira 7.2-7.5. Structure 5.2 will support Jira 7.6+.
If your Jira server does not have Structure yet, the installation is simple:
catalina.out
or jira-application.log
for log messages from Structure.If you're upgrading from version 2.11.2 or earlier, please read Structure 3.0.0 Release Notes.
The upgrade procedure from versions 3.x–5.0 is simple:
Install the new version of the plugin.
catalina.out
or jira-application.log
for warnings or errors.We strongly recommend that you back up your data before upgrading. The introduction of manual adjustments required changes to our backup file format, which makes previous versions of Structure unable to restore data from backup files created by Structure 5.0 and later. For more information, see Backup Format Version Change.
Structure 5.1 has a number of changes that are important for large-scale Jira Server and Jira Data Center instances.
"Structure Index Monitor" is a system custom field that is automatically installed on Jira Data Center instances since Structure 4.6. It helps Structure capture events related to Lucene-based index subsystem. This is what it looks like on the Jira administrator's Custom Fields page:
This custom field does not store any data in the index, so it does not have a performance impact. Structure Index Monitor field cannot be removed, but it will disappear if Structure is uninstalled and will not affect Jira at all.
One application of this field is ensuring correct cache operation in Structure. When an issue is updated on one node, the indexes on all nodes must be updated to make sure JQL queries return the correct result everywhere. Structure caches also need to be checked on all nodes, and potentially a JQL query should be re-run to make sure that generated content is up to date. The cache update should not happen earlier than the index update, otherwise a JQL query would return an outdated result.
With Structure 5.1, we use the Structure Index Monitor field to help with the timing of cross-node updates. It eliminates a chance of a race condition that would cause Structure to show outdated content on a particular node for a long time after a relevant update has happened.
To test the rollout of this change, you can observe the behavior of the system under a constant stream of issue updates (one change per second, for example), happening on one node, while a user observes a structure with JQL-based automation on another node. At some point the stream of changes should stop, and a few seconds later the user should see the most up-to-date information in Structure.
This feature has been experimental for a while, and we're enabling it now as the default. It is still possible to turn it off and go back to the way events were propagated between nodes in Structure 5.0 and earlier, by using the dark features interface and setting structure.delegatingItemTracker.enableReindexMonitor
to false
.
In the Data Center environment, Structure running on one node needs to let Structure running on other nodes know when an item (an issue or some other object) changes. This "change stream" is communicated to other nodes via the database, asynchronous caches and occasional use of a global, one-per-cluster lock.
Normally, each change is written into the database immediately when it happens – in the "event listener". That code runs in the same execution thread as the change itself, typically as a response to a user's action. We recently worked on an incident where the Jira global locking subsystem failed and there were certain issues with the database. That made writing of the change stream "hang", which, in turn, made user request threads hang, which led to Jira being unresponsive.
In Structure 5.1, we're introducing an alternative implementation of this subsystem, which would never block a user request thread. All global lock operations and writing to the database will happen in a separate, dedicated thread of execution.
This feature is currently not enabled by default. For now we recommend to turn it on if a similar problem has happened in the past, or if there's a problem with Jira hanging and you suspect it might be this case.
To enable this feature, set the structure.delegatingItemTracker.enableAsyncEventsQueue
property to true
in the dark features interface. For more information, see Advanced Configuration.
To test the change, use the same method as described in the previous section.
In preparations for the upcoming Jira 8 release, we have adjusted how Structure works with Lucene index and Jira search. This change should not affect performance or the users in any way. To test that everything is okay, one could run a JQL query from Structure | Query board.
One of the database tables that Structure most frequently uses is AO_8BAD1B_ROW
. Structures contain rows, and this table stores the mapping between unique numeric "row IDs" and arbitrary "item IDs" of the objects that structures contain. This table is used very often when a structure is displayed.
With Structure 5.1, we implemented a bulk operation that lets Structure get multiple row information with one database request. That greatly speeds up loading structures that have lots of manually added issues and reduces the database load.
To test this improvement, you can try creating a temporary structure, adding several thousands of issues there (manually, copying them from a search result), and then opening that structure after an upgrade or after Structure is disabled and enabled.
Apart from the specific suggestions given above, you can run the generic load and stress testing on a staging environment as advised in the previous release notes.
Should you have any questions on Enterprise Deployment, let us know at support@almworks.com.