During TRIRIGA install, we encountered “Build Failed” and the Oracle WebLogic log contained the following. What happened?
####<Jan 23, 2018 4:47:14 PM ART> <Error> <Deployer>
<S-Tririga> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <7bf5687e-a5eb-47f9-9610-fd0f96db07ae-0000042e> <1516736834996> <BEA-149265> <Failure occurred in the execution of deployment request with ID "7285840482438638" for task "2". Error is:
[Admin: To see other related posts, use the WebLogic or Installation tag.]
After upgrading to TRIRIGA 3.5.1.x or later, some customers are having issues with thumbnail images on reports and/or queries not being displayed correctly.
WebLogic incorrectly parses a JSP by adding white space that corrupts image thumbnails. Meanwhile, WebSphere and Liberty parse the JSP correctly. Moving forward, we resolved an issue where Oracle WebLogic was incorrectly interpreting TRIRIGA code, and injecting extra white space that caused thumbnail images to be displayed as broken images.
When I open the TRIRIGA Workflow Builder, I can’t see any workflows. But I see this error in the server.log file:
ERROR [com.tririga.platform.error.ErrorHandler]([ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)') Report handled exception: com.tririga.platform.error.PlatformRuntimeException: java.lang.RuntimeException: weblogic.servlet.jsp.CompilationException: Failed to compile JSP /html/en/default/wfBuilder/wftManagerList.jsp
wftManagerList.jsp:41:19: The type __wftmanagerlist.WorkflowComparator must implement the inherited abstract method Comparator.thenComparing(Function, Comparator)
This is a WebLogic bug. To resolve the issue, customers must go to the Oracle website to download, install, and apply a WebLogic patch (Patch 18729264).
[Admin: This post is related to the 09.26.16 post about APAR IV89199 where HTML code appears instead of workflows in Workflow Builder.]
I am installing TRIRIGA 3.5.0/10.5.0 on my local machine with WebLogic and Oracle 12c. But I am getting the following error:
[java] Connecting to system@jdbc:oracle:thin:@localhost:1521:orcl
[java] Exception encountered! java.sql.SQLException: ORA-65048: error encountered when processing the current DDL statement in pluggable database PDBORCL
[java] ORA-00959: tablespace 'TRIDATA_DATA' does not exist...
Installing to a pluggable database (PDB) or container database (CDB) is not supported in TRIRIGA 3.5.0. To resolve this, you will need to use the 3.5.2 platform installer or higher. Here is the 3.5.2 release note:
Installation: The installation of TRIRIGA Platform now supports connecting to Oracle via Service Name. This will allow you to use a RAC URL, or PDB installations. The installer will prompt for connecting via the older SID, or the Service Name as a section choice. (Tri-213951)
[Admin: This post is related to the 07.07.16 post and 01.26.16 post about getting an Oracle 12c error during install.]
Customers may receive a “java.lang.IllegalArgumentException” when attempting to create an Object Migration package of all of their associations. This occurs when the associations are searched for, selected, and you click “Add Selected Objects”.
The issue was that an OM that adds all associations to a package was exceeding the 10,000 maxParamSize limit in WebLogic. The fix is to require a module to be selected for association searches in OM. Moving forward, when creating an Object Migration export package, selecting a module is now required when searching for associations to add to the package.
What are the concerns about stopping my database for maintenance and leaving IBM TRIRIGA JVMs (JBoss, WebLogic, WebSphere) up and running at this point? Will they be reconnecting automatically after my database is up and running again? I need to programmatically schedule database maintenance for my TRIRIGA system.
When the database is down, the application server (JBoss, WebLogic, WebSphere) will be receiving connection issues to the JDBC component and JVMs will stop responding after that. If the database comes up again, the application server will not reconnect the JVM automatically. The JVM needs to be restarted manually after that.
The best practice for database maintenance requiring database shutdown will always be to shutdown all applications and sessions connected to it BEFORE the database itself. It gives systems the time to close the ongoing transactions gracefully.
If you need to coordinate database maintenance and JVMs automatic restarts, you need to create a batch script to manage that. This is a customized script (not under IBM TRIRIGA support) that will be stopping the JVMs first, then starting the database maintenance itself (likely stopping the database first), then restarting the database and firing commands to restart the application server IBM TRIRIGA JVMs.