dqp lifecycle issues -------------------- Key: TEIID-66 URL: https://jira.jboss.org/jira/browse/TEIID-66 Project: Teiid Issue Type: Bug Components: Embedded Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Ramesh Reddy Fix For: 6.0.0 There are some exceptions (see below) happening during Embedded shutdown. The CacheProvider looks like it's assuming that it's a true singleton, but the EmbeddedGuiceModule is created and the Injector is set on the ResourceFinder with ever EmbeddedConnection created. That's causing us to attempt the mbean registration and cache creation with every connection, which seems very troubling with simultaneous connections. What do you think about the following: 1. Why should we initiate an implicit shutdown with no connections? Why not implicitly start, but require an explicit shutdown. 2. We should at least promote the set of the injector to the constructor of EmbeddedConnectionFactoryImpl (assuming 1 jboss cache per dqp), however I don't know enough about how we're using JBoss cache to know if that will work. It seems like we would need to use a cache region per dqp, not a separate cache. But if it is one cache per, then at the very least we would need to also change our mbean registration to have unique names. 3. It looks like we can avoid the exception below if we first unregister the existing instance. Logically we'd like that to happen when JBossCacheFactory.destroy is called, so I'd be in favor of moving the mbean registration and dergistration logic into the JBossCacheFactory so that it has control over both sides. > javax.management.InstanceAlreadyExistsException: jboss.cache:service=MetaMatrixCacheTree > at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) > at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482) > at com.metamatrix.jdbc.CacheProvider.get(CacheProvider.java:51) > at com.metamatrix.jdbc.CacheProvider.get(CacheProvider.java:40) > at com.google.inject.BoundProviderFactory.get(BoundProviderFactory.java:60) From Ramesh: 3. Yes, this needs to be done. 2. DQP only uses the cache for the resultset caching. I am kind of on the fence about supporting multiple DQP instances, in a given VM. I do not see that as serving much of the usecases. So, if we can relax that requirement then we can always assume there is only one instance of the DQP. Otherwise, depending upon how we use Cache we should be able to segment cache by DQP instance identifier. 1. Except for re-loading times, do you see any issue with this? Original design wanted to see the Embedded as JDBC driver, such that when there are no connections, it unloads itself and reduces the memory footprint of the VM. It become more of who's responsibility is it to shutdown? If we deployed this app server, or in pre-built tool like Squirrel. Shutting down closes the connector bindings etc, that are active.