[JBoss JIRA] Updated: (TEIID-366) SFDC importer plugin has copies of lots of 3rd party jars that maybe should be in sep plugins
by Ramesh Reddy (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-366?page=com.atlassian.jira.plug... ]
Ramesh Reddy updated TEIID-366:
-------------------------------
Component/s: Common
Documentation
Misc. Connectors
Fix Version/s: 6.1.0
> SFDC importer plugin has copies of lots of 3rd party jars that maybe should be in sep plugins
> ---------------------------------------------------------------------------------------------
>
> Key: TEIID-366
> URL: https://jira.jboss.org/jira/browse/TEIID-366
> Project: Teiid
> Issue Type: Quality Risk
> Components: Common, Documentation, Misc. Connectors
> Affects Versions: 6.0.0
> Environment: Designer 5.5.3 MS1 build
> Reporter: Greg Haber
> Assignee: Van Halbert
> Priority: Minor
> Fix For: 6.1.0
>
>
> I noticed that as of MS1, the SFDC importer plugin contains a lot of copies of third party jars, most Apache Axis/Apache Commons stuff. In many cases, these same jars are also in the com.metamatrix.modeler.dqp_5.5.3 plugin since they are also needed by the SFDC connector. I also noticed that some of our other Designer plugins that use external jars put those jars in their own plugins, and import the plugin, rather than putting them in the same plugin as our own code.
> We should consider pulling these jars out of the SFDC importer plugin and putting them in their own plugins (which the SFDC importer plugin can then import), or simply importing them in the SFDC importer plugin from the DQP plugin.
> The same problem exists to a much lesser degree in the WSDL importer (just the commons-codec-1.2.jar is duplicated in that one).
--
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
15 years, 10 months
[JBoss JIRA] Updated: (TEIID-203) Make connector capabilites more granular.
by Ramesh Reddy (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-203?page=com.atlassian.jira.plug... ]
Ramesh Reddy updated TEIID-203:
-------------------------------
Component/s: Connector API
Query Engine
> Make connector capabilites more granular.
> -----------------------------------------
>
> Key: TEIID-203
> URL: https://jira.jboss.org/jira/browse/TEIID-203
> Project: Teiid
> Issue Type: Feature Request
> Components: Connector API, Query Engine
> Affects Versions: 6.0.0
> Reporter: John Doyle
> Assignee: Steven Hawkins
> Fix For: 6.1.0
>
>
> Some connector capabilites are only available in combination with others. For example, if you wish to support the SupportsAggregatesCount capability, you have to also support the SupportsAggregates capability(GROUP BY and HAVING). This requirement creates additional requirements for a connector where the source syustem cabilities do not correspond with the relationships we have defined between capabilites.
> For instance, the SQL supported by salesforce can include the count(*) function, but it does not support GROUP BY or HAVING. Because we require c connector to support SupportsAggregates befrore it can support count(*), the connector is required to implement those functions if it wishes to pus down count(*).
--
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
15 years, 10 months
[JBoss JIRA] Commented: (TEIID-66) dqp lifecycle issues
by Ramesh Reddy (JIRA)
[ 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
15 years, 10 months
[JBoss JIRA] Work started: (TEIID-66) dqp lifecycle issues
by Ramesh Reddy (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-66?page=com.atlassian.jira.plugi... ]
Work on TEIID-66 started by Ramesh Reddy.
> 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
15 years, 10 months
[JBoss JIRA] Commented: (TEIID-62) Error starting vmcontroller
by Ramesh Reddy (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-62?page=com.atlassian.jira.plugi... ]
Ramesh Reddy commented on TEIID-62:
-----------------------------------
I think we should put in a error message that lists the following the causes.
1) Firewall is blocking
2) Home network ISP is not routing to between the multiple network interfaces
3) Use "unicast" protocol
4) Try to use the "testutil" to resolve the issue, and point to a WIKI.
> Error starting vmcontroller
> ---------------------------
>
> Key: TEIID-62
> URL: https://jira.jboss.org/jira/browse/TEIID-62
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Fix For: 6.1.0
>
>
> The following exception is seen in the process log when starting server
> Feb 10, 2009 08:33:37.074 [main|0] ERROR <CONTROLLER|0> Failed to add VM:VMControllerID<1000>:DHCP-10.15.208.158.STL.REDHAT.COM
> com.metamatrix.platform.registry.ClusteredRegistryState$CacheNodeNotFoundException: Host Node not found=dhcp-10.15.208.158.stl.redhat.com
> at com.metamatrix.platform.registry.ClusteredRegistryState.getHostNode(ClusteredRegistryState.java:62)
> at com.metamatrix.platform.registry.ClusteredRegistryState.addVMNode(ClusteredRegistryState.java:68)
> at com.metamatrix.platform.registry.ClusteredRegistryState.addVM(ClusteredRegistryState.java:101)
> at com.metamatrix.platform.registry.VMMonitor.vmAdded(VMMonitor.java:150)
> at com.metamatrix.platform.vm.controller.VMController.initVMProperties(VMController.java:321)
> at com.metamatrix.platform.vm.controller.VMController.<init>(VMController.java:204)
> at com.metamatrix.common.comm.platform.socket.SocketVMController.<init>(SocketVMController.java:82)
> at com.metamatrix.common.comm.platform.socket.SocketVMController$$FastClassByGuice$$1b0a3540.newInstance(<generated>)
> at com.google.inject.cglib.reflect.FastConstructor.newInstance(FastConstructor.java:40)
> at com.google.inject.DefaultConstructionProxyFactory$2.newInstance(DefaultConstructionProxyFactory.java:67)
> at com.google.inject.ConstructorInjector.construct(ConstructorInjector.java:142)
> at com.google.inject.InjectorImpl$ImplicitBinding.get(InjectorImpl.java:1006)
> at com.google.inject.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:37)
> at com.google.inject.InjectorImpl.callInContext(InjectorImpl.java:756)
> at com.google.inject.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:35)
> at com.google.inject.Scopes$1$1.get(Scopes.java:53)
> at com.google.inject.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at com.google.inject.BindingBuilderImpl$FactoryProxy.get(BindingBuilderImpl.java:299)
> at com.google.inject.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:37)
> at com.google.inject.InjectorImpl.callInContext(InjectorImpl.java:756)
> at com.google.inject.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:35)
> at com.google.inject.Scopes$1$1.get(Scopes.java:53)
> at com.google.inject.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at com.google.inject.InjectorImpl$SingleFieldInjector.inject(InjectorImpl.java:473)
> at com.google.inject.ConstructorInjector.construct(ConstructorInjector.java:155)
> at com.google.inject.InjectorImpl$ImplicitBinding.get(InjectorImpl.java:1006)
> at com.google.inject.InjectorImpl$9$1.call(InjectorImpl.java:708)
> at com.google.inject.InjectorImpl.callInContext(InjectorImpl.java:747)
> at com.google.inject.InjectorImpl$9.get(InjectorImpl.java:702)
> at com.google.inject.InjectorImpl.getInstance(InjectorImpl.java:728)
> at com.metamatrix.server.Main.loadMain(Main.java:114)
> at com.metamatrix.server.Main.main(Main.java:102)
> Feb 10, 2009 08:33:37.074 [main|0] ERROR <CONTROLLER|0> Failed to add VM:VMControllerID<1000>:DHCP-10.15.208.158.STL.REDHAT.COM
> com.metamatrix.platform.registry.ClusteredRegistryState$CacheNodeNotFoundException: Host Node not found=dhcp-10.15.208.158.stl.redhat.com
> at com.metamatrix.platform.registry.ClusteredRegistryState.getHostNode(ClusteredRegistryState.java:62)
> at com.metamatrix.platform.registry.ClusteredRegistryState.addVMNode(ClusteredRegistryState.java:68)
> at com.metamatrix.platform.registry.ClusteredRegistryState.addVM(ClusteredRegistryState.java:101)
> at com.metamatrix.platform.registry.VMMonitor.vmAdded(VMMonitor.java:150)
> at com.metamatrix.platform.vm.controller.VMController.initVMProperties(VMController.java:321)
> at com.metamatrix.platform.vm.controller.VMController.<init>(VMController.java:204)
> at com.metamatrix.common.comm.platform.socket.SocketVMController.<init>(SocketVMController.java:82)
> at com.metamatrix.common.comm.platform.socket.SocketVMController$$FastClassByGuice$$1b0a3540.newInstance(<generated>)
> at com.google.inject.cglib.reflect.FastConstructor.newInstance(FastConstructor.java:40)
> at com.google.inject.DefaultConstructionProxyFactory$2.newInstance(DefaultConstructionProxyFactory.java:67)
> at com.google.inject.ConstructorInjector.construct(ConstructorInjector.java:142)
> at com.google.inject.InjectorImpl$ImplicitBinding.get(InjectorImpl.java:1006)
> at com.google.inject.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:37)
> at com.google.inject.InjectorImpl.callInContext(InjectorImpl.java:756)
> at com.google.inject.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:35)
> at com.google.inject.Scopes$1$1.get(Scopes.java:53)
> at com.google.inject.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at com.google.inject.BindingBuilderImpl$FactoryProxy.get(BindingBuilderImpl.java:299)
> at com.google.inject.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:37)
> at com.google.inject.InjectorImpl.callInContext(InjectorImpl.java:756)
> at com.google.inject.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:35)
> at com.google.inject.Scopes$1$1.get(Scopes.java:53)
> at com.google.inject.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at com.google.inject.InjectorImpl$SingleFieldInjector.inject(InjectorImpl.java:473)
> at com.google.inject.ConstructorInjector.construct(ConstructorInjector.java:155)
> at com.google.inject.InjectorImpl$ImplicitBinding.get(InjectorImpl.java:1006)
> at com.google.inject.InjectorImpl$9$1.call(InjectorImpl.java:708)
> at com.google.inject.InjectorImpl.callInContext(InjectorImpl.java:747)
> at com.google.inject.InjectorImpl$9.get(InjectorImpl.java:702)
> at com.google.inject.InjectorImpl.getInstance(InjectorImpl.java:728)
> at com.metamatrix.server.Main.loadMain(Main.java:114)
> at com.metamatrix.server.Main.main(Main.java:102)
> Exception in thread "main" com.google.inject.ProvisionException: Error while locating instance
> bound to com.metamatrix.platform.vm.api.controller.VMControllerInterface
> for member at com.metamatrix.server.Main.vmController(Main.java:58)
> at com.google.inject.InjectorImpl$SingleFieldInjector.inject(InjectorImpl.java:486)
> at com.google.inject.ConstructorInjector.construct(ConstructorInjector.java:155)
> at com.google.inject.InjectorImpl$ImplicitBinding.get(InjectorImpl.java:1006)
> at com.google.inject.InjectorImpl$9$1.call(InjectorImpl.java:708)
> at com.google.inject.InjectorImpl.callInContext(InjectorImpl.java:747)
> at com.google.inject.InjectorImpl$9.get(InjectorImpl.java:702)
> at com.google.inject.InjectorImpl.getInstance(InjectorImpl.java:728)
> at com.metamatrix.server.Main.loadMain(Main.java:114)
> at com.metamatrix.server.Main.main(Main.java:102)
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at com.google.inject.ConstructorInjector.construct(ConstructorInjector.java:161)
> at com.google.inject.InjectorImpl$ImplicitBinding.get(InjectorImpl.java:1006)
> at com.google.inject.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:37)
> at com.google.inject.InjectorImpl.callInContext(InjectorImpl.java:756)
> at com.google.inject.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:35)
> at com.google.inject.Scopes$1$1.get(Scopes.java:53)
> at com.google.inject.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at com.google.inject.BindingBuilderImpl$FactoryProxy.get(BindingBuilderImpl.java:299)
> at com.google.inject.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:37)
> at com.google.inject.InjectorImpl.callInContext(InjectorImpl.java:756)
> at com.google.inject.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:35)
> at com.google.inject.Scopes$1$1.get(Scopes.java:53)
> at com.google.inject.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at com.google.inject.InjectorImpl$SingleFieldInjector.inject(InjectorImpl.java:473)
> ... 8 more
> Caused by: java.lang.reflect.InvocationTargetException
> at com.metamatrix.common.comm.platform.socket.SocketVMController$$FastClassByGuice$$1b0a3540.newInstance(<generated>)
> at com.google.inject.cglib.reflect.FastConstructor.newInstance(FastConstructor.java:40)
> at com.google.inject.DefaultConstructionProxyFactory$2.newInstance(DefaultConstructionProxyFactory.java:67)
> at com.google.inject.ConstructorInjector.construct(ConstructorInjector.java:142)
> ... 21 more
> Caused by: Failed to add VM:VMControllerID<1000>:DHCP-10.15.208.158.STL.REDHAT.COM
> at com.metamatrix.platform.registry.VMMonitor.vmAdded(VMMonitor.java:154)
> at com.metamatrix.platform.vm.controller.VMController.initVMProperties(VMController.java:321)
> at com.metamatrix.platform.vm.controller.VMController.<init>(VMController.java:204)
> at com.metamatrix.common.comm.platform.socket.SocketVMController.<init>(SocketVMController.java:82)
> ... 25 more
>
--
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
15 years, 10 months