[
http://mifosforge.jira.com/browse/MIFOS-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=68987#comment-68987
]
Udai Gupta commented on MIFOS-5096:
-----------------------------------
Batch jobs runs operations much more than 30 seconds. In batch jobs the problem
is at transactional level. I am not sure but I won't be surprised if batch job
bind multiple operation under one transaction unnecessarily which can run for
hours using same connection.
Some operation which are not batch job might require more than 30 sec (e.g
center, group transfer).
unreturnedConnectionTimeout is not the ideal solution and should not be enabled
in the Mifos by default. I think this is a workaround, so we should at least
provide the way so that users can set this in local.properties (which I think
is not possible currently). But forced timeout should be disabled by default.
We don't want people to be surprised by this setting when a connection just
timeout during an upgrade.
> Configure c3p0 pool to never wait indefinitely for connections, and debug
> unreturned connections to identify leaks
> ------------------------------------------------------------------------------------------------------------------
>
> Key: MIFOS-5096
> URL: http://mifosforge.jira.com/browse/MIFOS-5096
> Project: mifos
> Issue Type: Improvement
> Reporter: Michael Vorburger
> Assignee: Michael Vorburger
> Priority: Critical
> Attachments: c3p0.properties
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> I've spent a few hours today digging into Connection Pooling to try to help
> with MIFOSSUPPORT-92.
> As part of that I've read http://www.mchange.com/projects/c3p0/, and would
> like to propose that we include the attached c3p0.properties.
> This configuration causes the c3p0 connection pool a) to never wait
> indefinitely for connections, and b) forcibly terminate connections that were
> likely - and tell us where they leaked from!
> We could also set that unreturnedConnectionTimeout to something higher than
> 30, if anybody thinks we should be more prudent.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
Mifos-issues mailing list
Mifos-issues@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mifos-issues
