Administrator 5.x: DB connections required by TRA and Administrator
Article ID: KB0089624
Updated On:
| Products | Versions |
|---|---|
| TIBCO Administrator | - |
| Not Applicable | - |
Description
Resolution:
Connections used by Domain Hawk agent:
A connection from the pool will be used whenever the Hawk Agent needs to read POF data that isn't already cached or needs to write POF data. This happens during deployments, updating status, synchronizing software, starting or stopping, or any other activity the Hawk agent performs. Connections are only held onto while communication is happening with the database and are then released. There is a wait time, so if the connection requests exceed the pool size for a short time, that is okay and the tasks will take turns using the connections. Because of the dynamic nature, it is impossible to state how many connections will be used. You could roughly use:
#of simultaneous deployments +1
as a relatively close value, but peaks could exceed that and most cases will be less.
Connections used by Administrator server:
There are separate pools for the data that go into SYS_<domain>.dat and the data that go into AUTH_<domain>.dat and each pool will independently resize between the minimum and maximum values. If there are application domains, then each of those will also have its separate connection pool.
What is the formula to calculate the number of DB connections needed by Admin Server? Is this depending on number of deployments?
(a) Domain data is DB Based and application is FILE Based.
The way Admin server uses connections to database is then basically the same as the Hawk agent, though there is more background processing which tends to increase the number of connections which are used.
(b) Domain data is DB Based and Application is DB Based.
You need to add one additional connection for every deployed application (i.e., each "dat file" in Case (a) when file based application data are used). Note that secondary servers will each use just as many connections, so if you have 3 secondary servers in addition to the primary, your totals would be multiplied by 4. WE DO NOT RECOMMEND THIS APPROACH, it is supported for legacy reasons, but should be discouraged.
As to the algorithm for each Admin server (assuming they don't have BWC, BE, BF, OF or EMA which can each add between 0 and 18 connections or Portal Builder which can add up to 100) it is:
# of applications < Actual connections < # of applications + 12
Total number of connections used by Admin/Hawk (upper limit in the typical scenario):
By reasonably assuming that each Hawk Agent uses 0 - 12 connections (normallyit will not exceed 3), the formula is rougly is:
apps * servers < Total Connections < (apps + 12) * servers + (machines * 12)
where servers refer to Admin servers.
As a rule of thumb you could simply recommend the following for a BW and Adapter deployment:
(apps + 2) * servers + (machines * 2)
If BW is doing HTTP authentication it may also use some connections temporarily.
(c) Domain is DB Based and Applicaitons are local deployment
and 18 connections or Portal Builder which can add up to 100) it is:
# of applications < Actual connections < 12
Total number of connections used by Admin/Hawk (upper limit in the typical scenario):
By reasonably assuming that each Hawk Agent uses 0 - 12 connections (normallyit will not exceed 3), the formula is rougly is:
servers < Total Connections < (12) * servers + (machines * 12)
where servers refer to Admin servers.
As a rule of thumb you could simply recommend the following for a BW and Adapter deployment:
(2) * servers + (machines * 2)
Debugging the connection pooling
You can add the following property to get more information about the connection pool.
*************************
java.property.ENABLE_POOL_WARN_LOG=true
*************************
You can use the expiry interval in AdministrationDomain.properties and AuthorizationDomain.properties minimum (>2000) so that we make sure that we do not have more
connections open.
************************
tibcoadmin.database.expiryInterval=2000
***********************
Note: We would have seperate connection pooling for administrator domain and authorization domain. Each application domain would have its own connection pooling.
For administrator, you would need comment the following in the tibcoadmin_<domain>.tra if you want the administrator to pick up the values that you had configured in
AdministrationDomain.properties and AuthorizationDomain.properties.
# The maximum number of database connections to cache per ConnectionPool.
#java.property.tibcoadmin.database.maxConnections=10
# The amount of time (in milliseconds) that database connections will be
# cached when not in use.
# java.property.tibcoadmin.database.expiryInterval=1800000
# The amount of time (in milliseconds) that a database connection request
# will have to wait before a time out occurs and an error is thrown.
# java.property.tibcoadmin.database.waitTimeoutInterval=30000
Connections used by Domain Hawk agent:
A connection from the pool will be used whenever the Hawk Agent needs to read POF data that isn't already cached or needs to write POF data. This happens during deployments, updating status, synchronizing software, starting or stopping, or any other activity the Hawk agent performs. Connections are only held onto while communication is happening with the database and are then released. There is a wait time, so if the connection requests exceed the pool size for a short time, that is okay and the tasks will take turns using the connections. Because of the dynamic nature, it is impossible to state how many connections will be used. You could roughly use:
#of simultaneous deployments +1
as a relatively close value, but peaks could exceed that and most cases will be less.
Connections used by Administrator server:
There are separate pools for the data that go into SYS_<domain>.dat and the data that go into AUTH_<domain>.dat and each pool will independently resize between the minimum and maximum values. If there are application domains, then each of those will also have its separate connection pool.
What is the formula to calculate the number of DB connections needed by Admin Server? Is this depending on number of deployments?
(a) Domain data is DB Based and application is FILE Based.
The way Admin server uses connections to database is then basically the same as the Hawk agent, though there is more background processing which tends to increase the number of connections which are used.
(b) Domain data is DB Based and Application is DB Based.
You need to add one additional connection for every deployed application (i.e., each "dat file" in Case (a) when file based application data are used). Note that secondary servers will each use just as many connections, so if you have 3 secondary servers in addition to the primary, your totals would be multiplied by 4. WE DO NOT RECOMMEND THIS APPROACH, it is supported for legacy reasons, but should be discouraged.
As to the algorithm for each Admin server (assuming they don't have BWC, BE, BF, OF or EMA which can each add between 0 and 18 connections or Portal Builder which can add up to 100) it is:
# of applications < Actual connections < # of applications + 12
Total number of connections used by Admin/Hawk (upper limit in the typical scenario):
By reasonably assuming that each Hawk Agent uses 0 - 12 connections (normallyit will not exceed 3), the formula is rougly is:
apps * servers < Total Connections < (apps + 12) * servers + (machines * 12)
where servers refer to Admin servers.
As a rule of thumb you could simply recommend the following for a BW and Adapter deployment:
(apps + 2) * servers + (machines * 2)
If BW is doing HTTP authentication it may also use some connections temporarily.
(c) Domain is DB Based and Applicaitons are local deployment
and 18 connections or Portal Builder which can add up to 100) it is:
# of applications < Actual connections < 12
Total number of connections used by Admin/Hawk (upper limit in the typical scenario):
By reasonably assuming that each Hawk Agent uses 0 - 12 connections (normallyit will not exceed 3), the formula is rougly is:
servers < Total Connections < (12) * servers + (machines * 12)
where servers refer to Admin servers.
As a rule of thumb you could simply recommend the following for a BW and Adapter deployment:
(2) * servers + (machines * 2)
Debugging the connection pooling
You can add the following property to get more information about the connection pool.
*************************
java.property.ENABLE_POOL_WARN_LOG=true
*************************
You can use the expiry interval in AdministrationDomain.properties and AuthorizationDomain.properties minimum (>2000) so that we make sure that we do not have more
connections open.
************************
tibcoadmin.database.expiryInterval=2000
***********************
Note: We would have seperate connection pooling for administrator domain and authorization domain. Each application domain would have its own connection pooling.
For administrator, you would need comment the following in the tibcoadmin_<domain>.tra if you want the administrator to pick up the values that you had configured in
AdministrationDomain.properties and AuthorizationDomain.properties.
# The maximum number of database connections to cache per ConnectionPool.
#java.property.tibcoadmin.database.maxConnections=10
# The amount of time (in milliseconds) that database connections will be
# cached when not in use.
# java.property.tibcoadmin.database.expiryInterval=1800000
# The amount of time (in milliseconds) that a database connection request
# will have to wait before a time out occurs and an error is thrown.
# java.property.tibcoadmin.database.waitTimeoutInterval=30000
Issue/Introduction
Administrator 5.x: DB connections required by TRA and Administrator
Feedback
Yes
No
Powered by
