11:09 a.m.
[
https://jira.jboss.org/jira/browse/TEIID-66?page=com.atlassian.jira.plugi...
]
Ramesh Reddy commented on TEIID-66:
-----------------------------------
Embedded will have at most one instance per VM running at any given time. The URL used
during the very first connection is used as the identifier, when a separate connection
with different connection URL tries to connect then the previous connections are closed
and previous Embedded engine will be closed and a new one will be created.
In a given VM, once the connection is made and engine is active, all the activities can be
conducted as normal, however once the last connection is closed the engine will *not*
automatically shutdown, but will stay alive to until the next caller for the connection or
until VM shutdown. However user can explicitly call shutdown and unload the engine if
needed. This will reduce the expensive reloads and of the engine and play well with
connection pools in the app servers.
Embedded kit is getting a old style client driver, that can be used to make connections to
Embedded engine. Embedded has provision to load mandatory required dependent jars using a
non-delegating class loader from "lib" directory. The embedded will also have
"lib/patches" directory where it can load jars in "reverse alpha "
fashion to aid releasing the patches. As always you can put all jars in the boot-class
loader to make ti work too.
So that takes care of 1 & 2 above.
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira