I am attempting a clean install of TRIRIGA 3.5.3 and according to the logs, it appears that the installation was successful within the was-ant.log. But I receive this error in the ant.log… When I access the application, I was unable to pull up the login page. Checking the server logs, I noticed these errors… The odd thing is that when I did a TRIRIGA 3.5.3 install on WebSphere Liberty, it worked perfectly…
The errors seem to indicate that you selected an upgrade, not a new install. Are you sure you selected a new install? Some of the environment properties that are needed to start up do not seem to be available. Did the database get created or are you pointing at an existing database? What happens if you do a select * from environment_properties on the database you are using?
The DB2 exception you are receiving seems to indicate you are running out of statement handles, but it’s hard to see this happen with a successful install.
[Admin: To see other related posts, use the WebSphere tag or “install error” search phrase.]
In one of our environments, we have a large amount of records that have been transitioned to the null state. When the Cleanup Agent runs, it runs out of DB2 transaction log space executing the following:
DELETE FROM IBS_SPEC_ASSIGNMENTS WHERE EXISTS (SELECT ‘X’ FROM IBS_SPEC_CA_DELETE WHERE IBS_SPEC_CA_DELETE.SPEC_ID=IBS_SPEC_ASSIGNMENTS.SPEC_ID)
For workflow instance saves, the Cleanup Agent now seems to remove the data in small chunks (of 1000 rows each). But for the record data cleanup, it still seems to (try to) remove all data in one huge SQL statement/transaction. Is it possible to get the Cleanup Agent to remove record data in chunks, like it does for workflow instance saves?
Otherwise, I’m thinking of writing a small util that would run the statement above, but in smaller chunks, since it seems we still have the list of record IDs that it tries to remove in the IBS_SPEC_CA_DELETE table. Any obvious issues with that?
As of 3.5.3, there have been no changes for the data to be deleted in chunks for IBS_SPEC_ASSIGNMENTS. This sounds like a good PMR. It is rarely recommended to delete records directly from the database, but in this circumstance, you might be okay. However, the IBS_SPEC_CA_DELETE only exists during the time the Cleanup Agent is running. It is dropped when the agent goes back to sleep.
[Admin: To see other related posts, use the Cleanup tag or SQL tag. As a side note, starting with version 3.4, the Cleanup Agent name was changed to Platform Maintenance Scheduler.]
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.]
Recently, I have been getting some connectivity issue with TRIRIGA 3.5.2.x and DB2 on (Red Hat) RHEL 7.2. The connection between TRIRIGA breaks suddenly and the app crashes. When I see the error logs, it says:
2017-04-20 08:01:33,694 ERROR [com.tririga.design.smartobjecttype.dataaccess.DBConnectionDAO](DataImportAgent) FAILED DATA CONNECTION java.sql.SQLNonTransientException: [jcc][t4][4.18.60] Exception java.net.ConnectException: Error opening socket to server localhost/127.0.0.1 on port 50,000 with message: Connection refused (Connection refused). ERRORCODE=-4499, SQLSTATE=08001 DSRA0010E: SQL State = 08001, Error Code = -4,499
Caused by: com.ibm.db2.jcc.am.DisconnectNonTransientConnectionException: [jcc][t4][4.18.60] A communication error occurred during operations on the connection's underlying socket, socket input stream, or socket output stream. Error location: Reply.fill() - insufficient data (-1). Message: Insufficient data. ERRORCODE=-4499, SQLSTATE=08001
On the login page, it asks me to contact the system administrator. I have to restart the app and the database to make it work again. Interestingly, the app and the database server are on the same machine/VM. As always, any help is appreciated.
This almost looks like an ipTables or some sort of SecureLinux function getting in the way of the network connection and terminating it. Have you tested it by turning off the seLinux services and ipTables? If it runs better, then start adding rules to prevent the secure frameworks from stepping on the network connections.
Is there any reason why the DB2 tablespace creation script specifically creates the DB2 DMS tablespaces as old “REGULAR” tablespaces instead of the default “LARGE” tablespaces? I believe “LARGE” has been the default since DB2 v9 over a decade ago.
If not, would it be possible to change the tablespace creation statement in database/db2/new/createtbspace.sql (and I guess as a consequence, the TRIRIGA installer) from “CREATE REGULAR TABLESPACE” to “CREATE TABLESPACE”?
One of our customers is trying to apply all the best practices from the TRIRIGA documentation with different recommendations. One of them is regarding:
- ALLOW_SNAPSHOT_ISOLATION: SET ALLOW_SNAPSHOT_ISOLATION should be set to ON
- READ_COMMITTED_SNAPSHOT: SET READ_COMMITTED_SNAPSHOT should be set to ON
Their database department is telling them that if they activate this parameter, they could be doing “dirty reads”. Mainly, if they read and modify in the same tables at the same time. They said that other products control this situation. They wanted to know if TRIRIGA controls it. In case that TRIRIGA controls these situations, they will change it. Can you please confirm if they should set this parameter to ON?
TRIRIGA controls data integrity within the context of the web application. These settings for MS SQL make it behave more like Oracle and DB2, and we recommend that they be set to ON.
We are working on a DB2-to-Oracle migration for TRIRIGA 3.5.2/10.5.2 by using SQL*Loader. The TRI_REORG_ANALYSIS table recently caught our eye. This table exists in DB2, but does not exist in Oracle. But today, after we generated a new DB2 backup, this table is no longer there.
My question is: Is this a temporary table used for calculation or cache purposes?