Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#121 JMX beans registrations are no unregistred producing memory leak

v1.0 (example)
closed-fixed
nobody
None
5
2014-10-05
2013-09-15
No

JMX beans registrations for each pool is not unregistered while closing the pool.

I still see the beans named like this:
com.mchange.v2.c3p0:type=PooledDataSource,identityToken=2rxcmq8x8uayle1crg1ru|e9a0bf7,name=db

the com.mchange.v2.c3p0:type=C3P0Registry is unregistered.

Used to work in 0.9.1.2 version
0.9.5-pre4 and 0.9.2.1 producing the problem.

details:
JVM: Oracle 1.7.0_25
ComboPooledDataSource is used
((ComboPooledDataSource) dataSource).close(); called when web application is stopped.

Discussion

  • Looks like the default configuration for single application working fine.

    I see no sources in this SNAPSHOT so I can't really do/test what I did before.
    The requirements is to have multiple applications deployed on same tomcat with different names. (e.g. QA environment) see the screenshot.

    Each application have its own class loader. and independent connection pools and C3P0Registry

    To achieve this I copied the ActiveManagementCoordinator and changed as in attachment.
    just changing C3P0_REGISTRY_NAME depending on application context.

    Would be nice to hear how the default C3P0 configuration is suited to handle this cases.

    I have seen https://github.com/swaldman/c3p0/blob/master/src/dist-static/RELEASE_NOTES-c3p0-0.9.2
    "You can use the dataSourceName config parameter to create stable patterns in JMX mBeans"

    But have not found documentation for this.

    Having ability to extends ActiveManagementCoordinator and just override the ObjectName creation would be nice.

     
  • Steve Waldman
    Steve Waldman
    2013-12-04

    • status: open --> closed-fixed
     
  • The memory leak problem is resolved. Thanks you.
    I can do all using property files that are specific for application deployment.

    The problem with dynamic configuration in java remains.

    here what I ended up doing:

    package com.mchange.v2.c3p0.management;
    
    public class ActiveManagementCoordinatorExt extends ActiveManagementCoordinator {
    
        public ActiveManagementCoordinatorExt() throws Exception {
            super();
            regName = "com.mchange.v2.c3p0:type=C3P0Registry" + ",name=" + ContainerConfig.getContextName();
        }
    
    }
    

    If there will be a way to do something like this this would be nice.

    C3P0Config.getMultiPropertiesConfig().setProperty( C3P0_REGISTRY_NAME_KEY, ContainerConfig.getContextName())
    

    "Each application" in my case is the same web application war.
    the same code base, the same web.xml and c3p0.properties files. only different deployment context that IT can select at heir discretion at deployment time.

    e.g. app1, app2, app3

    So I can have on the same Tomcat multiple versions of the same application.

     
    Last edit: Vlad Skarzhevskyy 2014-05-28
  • Steve Waldman
    Steve Waldman
    2014-10-05

    Hi. So this is now possible (as of c3p0-0.9.5-pre9, to be released tomorrow I hope, available now as snapshot).

    The code you would want would look something like this:

    import com.mchange.v2.cfg.MultiPropertiesConfig;
    import com.mchange.v2.c3p0.cfg.C3P0Config;
    
    Properties overrideProps = new Properties();
    overrideProps.put( C3P0_REGISTRY_NAME_KEY, ContainerConfig.getContextName() );
    MultiPropertiesConfig overrides = MultiPropertiesConfig.fromProperties( overrideProps );
    C3P0Config.refreshMainConfig( overrides, "Set webapp specific C3P0Registry name." );
    

    I haven't actually tried this out, just added the missing API ;) If it would still be helpful to you, you might try giving it a shot.