New and Noteworthy in 5.1.0
TRS Performance and Features Improvements
-
The TRS events of large operations, like enabling or disabling OSLC on projects, are now
integrated into the TRS Feed outside of business hours (at 10 p.m. by default) to reduce
network traffic and preserve the application's responsiveness during operational hours.
-
The TRS Feeds can be validated (by project or entirely) to find not-yet integrated changes,
or other possibly missed events due to system instability (like shutting down a cluster
node or disabling the plugin) and apply them after confirmation, if required:
-
All the resources of a single project can be forced to be fetched by the consuming
applications to ensure that all of them have the latest version of the former without
rebuilding the whole feed.
-
The configurable TRS Repair Job to automatically repair all the TRS Feeds at the convenient time.
-
Download the Feed to inspect what are the consuming applications fetching.
-
Direct access to the Audit Log where most important TRS actions are tracked:
-
Delayed TRS Feeds initialization to enforce the new not-in-working-hours policy.
Since initializing a Feed can produce a large amount of TRS traffic, they are no
longer initialized on the first fetching request they get by the consuming
applications, typically ELM's LDX and LQE. This applies only to fresh installations
and has no impact on systems where TRS Feeds are already initialized. Consuming
datasources can still be registered, even if the Feed is not yet initialized, but
will be reporting
service unavailable errors until the Feed get finally
initialized either by the TRS Repair Job or manually. The following screen can be
seen while registering the Feed as datasource:
Downgrading is supported.
