mike_se Contributor.

PPM Support Tip: To show Connection Pool information, error information is displayed

When viewing the Broker In User Sessions Report and Connections Details page, expected behavior may look like errors to Administrators

To view open database connections on the front end, there is a server.conf paramter:

And to view the code used to open database connections in the Broker In User Sessions Report (run in Workbench or with kRunAdminServerReport.sh file), there is a server.conf:

These are used to find connection leaks. That means connections are staying open to the point where all of the connections are used and Project and Portfolio Management (PPM) becomes unresponsive and a restart of the Node is required to free the database connections.

When viewng the information, sometimes the expected behavior's information returned looks like an error to PPM Administrators and raises unwarranted concern.

Both the Connections Details page and the Broker In Use Sessions will show what look to be errors.

In the Connections Details page:
at com.mercury.itg.core.debug.util.DebugUtils.connectionDebug(DebugUtils.java:464)


Will typically have some connections on the correlation page that are not necessarily leaked, as they might just be sitting in the pool, waiting for some code to pick them up.

A connection, when closed in the code, is typically not closed, but is put back in the Connection Pool. When another piece of code will need a database connection, it will be taken out of the pool, still opened, saving PPM precious time as opening a connection to the database is time consuming.

The Database Connection correlation page is needed to pinpoint connection leaks, and when such a connection leak occurs it is very easy to find it on this screen as there will be many old connections issued in the same place.

In the Broker In Use Sessions Report:
"23437   -1   true user1  false      February 7, 2014 10:24:33 AM EST TP-Processor29:
at com.kintana.core.db.DBConnectionBroker.getNewDBSession(DBConnectionBroker.java:448)

PPM throws a RuntimeException in the code to get a StackTrace to be displayed in the report, so it can be knows where the connection was retrieved in the PPM code. It is the same thing as done on the Connection Correlation page, except there is not a nice ranking of connection by acquisition age, so there's a bit more work if wanting to find traces of a connection leak just on the Broker in Use Sessions Report.

“HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
Labels (1)
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.