Starting in version 3.5.3, IBM TRIRIGA Application Platform includes a Performance Analyzer. The Performance Analyzer is a system tool that helps you to diagnose system performance issues.
Performance Analyzer overview
- The Performance Analyzer provides a more streamlined approach to troubleshooting performance issues than the traditional IBM TRIRIGA performance log analysis.
- The Performance Analyzer helps you to better isolate and analyze the causes of performance issues by generating a log that is more targeted at the problem area. When you contact IBM to report a TRIRIGA performance issue, you might be asked to run the Performance Analyzer and provide the resulting data.
- When you select the performance timing categories that you want and start a performance run, the analyzer rolls the performance log and captures data while you do the process or actions that cause the slowness.
- When you stop the performance run, the analyzer automatically loads the performance data and does a high-level analysis that shows the longest running item in each category in the performance run. A result summary of the performance run shows the top events that took the longest time to run. You can further analyze the data by reviewing the result details where all the selected category data is displayed.
- You can also upload an existing performance log to the analyzer and the analyzer does the same high-level analysis of the data.
The Performance Analyzer has the same base requirements and restrictions as the traditional TRIRIGA performance logging, which includes nightly rolling, space consumption, and logs for all users. Details include…
[Admin: This post is related to the 02.10.17 post about finding the performance best practices. To see other related posts, use the Performance tag.]
After performing a TRIRIGA platform upgrade, some of the floor plans are not visible in the forms. Why aren’t they visible?
The TRIRIGA server cache needs to be refreshed. In other words, you need to clear the caches and restart the server. Here are more-detailed steps to clear your TRIRIGA cache and log folder:
- Login to the Admin Console.
- Go to the “Cache Manager” managed object.
- Click on the “All Caches (Global)” link and then “Hierarchy Tree Data – with rebuild” link. The process might take some time.
- Go to the “Database Manager” managed object, and click on the “Reprocess published drawings” link. Give the process some time to finish. Go to the current server log, and look for a related entry saying that the reprocess published drawing actions are finished. You will find a message similar to the following:
“INFO [com.tririga.platform.graphics.vector.drawing.DrawingService](http-0.0.0.0-21001-7) Finished re-processing drawings”
- Logout of the Admin Console.
- Stop the TRIRIGA JVMs via the WebSphere Admin Console.
- Delete the logs in the <TRIRIGA install>/log folder that has server.log.
- Clear the WebSphere temporary cache folder.
- Restart the TRIRIGA JVMs via the WebSphere Admin Console.
[Admin: This post is related to the 07.15.16 post about floor plan graphics disappearing after an upgrade, and the 09.29.14 post about clearing the TRIRIGA application server cache area. To see other related posts, use the “floor plan” or “clear cache” search phrase.]
This wiki is meant to help you troubleshoot and provide a workaround for the following publish error in MicroStation. It has primarily been seen in Select Series 4, but could happen in earlier versions of MicroStation. When publishing, the publish will fail. When you look at the server log, if you see the following error, then this issue is involved (the ACDSDATA, in particular):
com.tririga.platform.error.PlatformRuntimeException: Error processing DXF - last line read: 23500. Error: com.tririga.platform.graphics.vector.dxf.processor.UnexpectedGroupDataException: DXF contained an unexpected section type: Group-code:2 Value:'ACDSDATA' Source line:23499...
This error occurs due to the way in which MicroStation creates its DXF file for publishing for TRIRIGA, depending on its settings. The fix below is used to update MicroStation’s DXF output options to output using the “2010/2011/2012” format…
[Admin: This post is related to the 10.20.16 post about CI failing to publish. To see other related posts, use the MicroStation tag.]
I am experiencing an error with a smart section that was working just a week ago. This smart section exists across various environments, but is now causing an error in the development environment. I have experimented with the following:
- Removing the smart section causes record to show properly.
- Association and reverse association are both set properly.
- Removing all fields from the smart section causes the record to show properly, but adding any one field results in an error again.
- I can move the smart section to another tab and the rest of the record shows properly, until I click on the tab with the smart section.
- I have already tried object migrating the business object and form from an environment that works.
In the server log, this is error that shows:
440 ERROR [com.tririga.platform.error.ErrorHandler](WebContainer : 16) Report handled exception: com.tririga.platform.gui.rendering.GuiRenderingException: Could not render Gui Component: GuiTabMetadataImpl[Name=triGeneral,ID=14,GUI=GuiMetadataImpl[Name=tdbREProjectAuction,ID=10048479]] for record: SmartObjectImpl[ID=SmartObjectId[ID=47510356,Business Object ID=10002876],Business Object=BoImpl[name=triREProject,id=10002876,module=ModuleImpl[name=triProject,id=19]]][MID-3549400938]...
[Admin: This post is related to the 05.25.17 post about a GUI rendering issue. To see other related posts, use the Smart Section tag.]
I am getting a strange error when I am trying to deploy to TRIRIGA with the WebSphere Application Server (WAS). TRIRIGA doesn’t come up and throws an exception. Interestingly, when I point a Liberty application on the same DB2 database, it works well. I have confirmed with my network team that this is not a network connectivity issue. Here are the error logs:
Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: DB2 SQL Error: SQLCODE=-805, SQLSTATE=51002, SQLERRMC=NULLIDR1.SYSSH200 0X5359534C564C3031, DRIVER=4.18.60 DSRA0010E: SQL State = 51002, Error Code = -805...
Have you checked to see that both the Liberty server and the WAS server are actually using the exact same version of the DB2 driver (db2jcc4.jar)?
[Admin: To see other related posts, use the DB2 tag or JDBC tag.]
When a BIRT report is launched in TRIRIGA on the Reports tab or elsewhere, a Progress Bar popup appears with a “Cancel” button.
- 1. If I click “Cancel”, will that kill the Select statement that is running against the database on the database server?
- 2. If I click “Cancel”, will that release the database connection that is used when a BIRT report starts to run?
The answer to both questions is “No”. The thread will be consumed until the Select statement is complete. There is no messaging included in the log that the Select process was orphaned due to user interaction. The process simply continues to run until the results are retrieved and then stops. So, effectively:
- 1. No, canceling a request will not kill the Select statement.
- 2. No, the thread remains unaware that the request was canceled.
When the results are returned, the thread will process them, and then hit the canceled thread. There may be a message in the log warning about an IO socket being disconnected, or some other exception dealing with the dead connection.
[Admin: To see other related posts, use the Thread tag or BIRT tag.]