[
https://issues.apache.org/jira/browse/OMID-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16364586#comment-16364586
]
ASF GitHub Bot commented on OMID-87:
------------------------------------
Github user asfgit closed the pull request at:
https://github.com/apache/incubator-omid/pull/21
> Fix BatchPool initialization
> ----------------------------
>
> Key: OMID-87
> URL: https://issues.apache.org/jira/browse/OMID-87
> Project: Apache Omid
> Issue Type: Bug
> Affects Versions: 0.8.2.0
> Reporter: Francisco Perez-Sorrosal
> Assignee: Francisco Perez-Sorrosal
> Priority: Critical
> Labels: batch, batchpool, creation, fix
> Fix For: 0.9.0.0
>
>
> When initializing the ObjectPool for Batch java objects in
> BatchPoolModule.java, an Apache's GenericObjectPool is used. The pool
> configuration lacks the call to config.setMaxIdle(int), which provokes that
> when the Batch objects are returned to the ObjectPool during the pre-creation
> phase, those above the default max idle number of objects in the pool (which
> is 8 according to the [Apache
> documentation|https://commons.apache.org/proper/commons-pool/api-1.6/org/apache/commons/pool/impl/GenericObjectPool.html])
> are destroyed.
> If at some point the TSO needs to access those Batch objects between 8 and
> the number specified in the Omid configuration (numConcurrentCTWriters), they
> will be created on the fly, which it was we want to avoid when pre-creating
> the ObjectPool during the TSO initialization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
