]
Ramesh Reddy reassigned TEIID-66:
---------------------------------
Assignee: Ramesh Reddy (was: Steven Hawkins)
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: