[KULRICE-8268] broker pool optimization (4067) Created: 21/Sep/12  Updated: 29/May/15

Status: Open
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: None
Fix Version/s: Backlog
Security Level: Public (Public: Anyone can view)

Type: Improvement Priority: Major
Reporter: Bin Gao Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: Old
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Similar issues:
KULRICE-3531Borrow broker from pool failed
KULRICE-11871IT Failure PersonServiceImplTest.testLookupWithPersonJoin PBFactoryException: Borrow broker from pool failed, using PBKey org.apache.ojb.broker.PBKey
KULRICE-377Revist thread pooling strategy
KULRICE-9432Optimize code in ViewHelperServiceImpl
KULRICE-7944Change view pooling to use a thread pool
KULRICE-2673Optimize the RuleService.getDuplicateRuleId check
KULRICE-10549Thread pool configuration and queueing algorithm
KULRICE-6757KSPD: Investigate Optimization options for ViewServiceImpl
KULRICE-7185Optimization of KIM Permission Checks
KULRICE-14262Optimize Amazon RDS usage
Rice Module:
Rice Core
KAI Review Status: Not Required
KTI Review Status: Not Required
Contributing Institution: Michigan State Univ

 Description   

optimize the broker pool so it does not grab as many new brokers.

This is brief description of the PersistenceBroker issue which we faced in MSU and fixed :
Actaully there is a file called OJB.properties which is used while initializing the OJB configuration during the application start up.
We have a property called maxActive which specifies the number of persistenceBrokers that are available at a point of time .
Since we use OJB as ORM access to each db call is made through the PersistenceBroker object.
Edocs in PURAP module like Requisition and recurring PREQS makes use of lot of PB objects eventually exceeding the max active count as a result this
exception usually arises :
org.springframework.dao.DataAccessResourceFailureException: Could not open OJB PersistenceBroker; nested exception is org.apache.ojb.broker.PBFactoryException: Borrow broker from pool failed, using PBKey org.apache.ojb.broker.PBKey: jcdAlias=enWorkflowDataSource, user=null, password=null

Caused by:

org.apache.ojb.broker.PBFactoryException: Borrow broker from pool failed, using PBKey org.apache.ojb.broker.PBKey: jcdAlias=enWorkflowDataSource, user=null, password=null

at org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.createPersistenceBroker(PersistenceBrokerFactoryDefaultImpl.java:120)

at org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl.createPersistenceBroker(PersistenceBrokerFactorySyncImpl.java:122)

at org.apache.ojb.broker.PersistenceBrokerFactory.createPersistenceBroker(PersistenceBrokerFactory.java:104)

at org.springmodules.orm.ojb.OjbFactoryUtils.getPersistenceBroker(OjbFactoryUtils.java:86)

at org.springmodules.orm.ojb.PersistenceBrokerTemplate.getPersistenceBroker(PersistenceBrokerTemplate.java:286)

at org.springmodules.orm.ojb.PersistenceBrokerTemplate.execute(PersistenceBrokerTemplate.java:139)

at org.springmodules.orm.ojb.PersistenceBrokerTemplate.getReportQueryIteratorByQuery(PersistenceBrokerTemplate.java:209)

Caused by: java.util.NoSuchElementException

at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:758)

... 160 more

The above exception describes the pool maintained by PersistenceBrokerFactoryDefaultImpl the factory implementation which is responsible for
maintaining the life cycle of PersistencBroker object is running out of objects since the limit is reached .

When ever we make a call to DB for doing any operations the currently running thread checks whether it is bound to a Transaction Manager if it founds a transaction
then from it tries to find the PB object bound to the current thread and releases it back to the pool after finishing , if it is not bound to any transaction manager
then each operation to the DB borrows separate brokers and returns it to pool after it finishes.



 Comments   
Comment by Jessica Coltrin (Inactive) [ 11/Feb/13 ]

moving all non-critical 2.1.3 Jiras to 2.1.4

Comment by Shannon Hess [ 21/May/15 ]

You mentioned above that this relates to the PersistenceBroker issue which you faced at MSU and fixed. Could you possibly explain further how you were able to fix this issue?

Thanks,
Shannon

Comment by Bin Gao [ 29/May/15 ]

Hello Shannon, I am working on a different project and don't have the code and document for this fix. You can contact Shyam Gedela for more details. I put him as one of watchers. Thanks! --Bin

Generated at Sun Jun 07 00:57:58 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.