[JBoss JIRA] Commented: (TEIID-62) Error starting vmcontroller
by Van Halbert (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-62?page=com.atlassian.jira.plugi... ]
Van Halbert commented on TEIID-62:
----------------------------------
The problem was the firewall setting on the mac. once it was turned off, the server started
> 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
[JBoss JIRA] Created: (TEIID-347) Procedural relational and exec queries should not project out or return parameters
by Steven Hawkins (JIRA)
Procedural relational and exec queries should not project out or return parameters
----------------------------------------------------------------------------------
Key: TEIID-347
URL: https://jira.jboss.org/jira/browse/TEIID-347
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 6.0.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 6.0.0
IN_OUT, OUT, and RETURN parameters cannot be returned as projected symbols since the result set only contains the values at the end in a diagonal matrix. We are already filtering this situation out on the JDBC client side, but we need to ensure that the exec and proc relational queries are correctly interpreted on the server side.
IN_OUT parameters will have their IN parameters projected without the _IN suffix - this is a breaking change, but it is unlikely that a customer was using proc relational with source procedures using in_out parameters.
--
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] Resolved: (TEIID-169) We should clarify the one-to-one relationship between Batch interface and BasicBatch class in the Connector API
by Steven Hawkins (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-169?page=com.atlassian.jira.plug... ]
Steven Hawkins resolved TEIID-169.
----------------------------------
Resolution: Done
Changed BatchedExecution to ResultSetExectuion, which has a next() method to return results iteratively. There is no need for explicit batching by the connector.
> We should clarify the one-to-one relationship between Batch interface and BasicBatch class in the Connector API
> ----------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-169
> URL: https://jira.jboss.org/jira/browse/TEIID-169
> Project: Teiid
> Issue Type: Sub-task
> Components: Connector API
> Affects Versions: 6.0.0
> Reporter: Greg Haber
> Assignee: Steven Hawkins
> Priority: Optional
> Fix For: 6.0.0
>
>
> When a connector implements the BatchedExecution interface, it is required to implement a method nextBatch() that returns a Batch. Batch is an interface, and technically can be implemented however the connector developer wants, as long as it implements "void addRow(List row)" and "List[] getResults()" - the implementation could theoretically store the current Batch state internally in a structure that was not a List[] and just do the needed conversions in these two methods.
> However, in every known connector the implementation of BatchedExecution just uses the BasicBatch implementation we provide for Batch, which takes the straightforward path and stores the batch internally as an ArrayList.
> This best practice is not obvious from the API itself (or even from the doc) - in the legacy MetaMatrix product we have had an instance where a developer built his own implementation of Batch (and somehow ran into trouble doing so).
> Perhaps we should make this best practice more obvious - one thought is that Batch should be an abstract class rather than an interface - or perhaps BatchedExecution should require that nextBatch return BasicBatch or an extension of BasicBatch - or perhaps we should leave the API as is in this regard and just highlight this in the doc (and javadoc).
--
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-169) We should clarify the one-to-one relationship between Batch interface and BasicBatch class in the Connector API
by Steven Hawkins (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-169?page=com.atlassian.jira.plug... ]
Steven Hawkins updated TEIID-169:
---------------------------------
Parent: TEIID-164
Issue Type: Sub-task (was: Feature Request)
> We should clarify the one-to-one relationship between Batch interface and BasicBatch class in the Connector API
> ----------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-169
> URL: https://jira.jboss.org/jira/browse/TEIID-169
> Project: Teiid
> Issue Type: Sub-task
> Components: Connector API
> Affects Versions: 6.0.0
> Reporter: Greg Haber
> Assignee: Steven Hawkins
> Priority: Optional
> Fix For: 6.0.0
>
>
> When a connector implements the BatchedExecution interface, it is required to implement a method nextBatch() that returns a Batch. Batch is an interface, and technically can be implemented however the connector developer wants, as long as it implements "void addRow(List row)" and "List[] getResults()" - the implementation could theoretically store the current Batch state internally in a structure that was not a List[] and just do the needed conversions in these two methods.
> However, in every known connector the implementation of BatchedExecution just uses the BasicBatch implementation we provide for Batch, which takes the straightforward path and stores the batch internally as an ArrayList.
> This best practice is not obvious from the API itself (or even from the doc) - in the legacy MetaMatrix product we have had an instance where a developer built his own implementation of Batch (and somehow ran into trouble doing so).
> Perhaps we should make this best practice more obvious - one thought is that Batch should be an abstract class rather than an interface - or perhaps BatchedExecution should require that nextBatch return BasicBatch or an extension of BasicBatch - or perhaps we should leave the API as is in this regard and just highlight this in the doc (and javadoc).
--
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-169) We should clarify the one-to-one relationship between Batch interface and BasicBatch class in the Connector API
by Steven Hawkins (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-169?page=com.atlassian.jira.plug... ]
Work on TEIID-169 started by Steven Hawkins.
> We should clarify the one-to-one relationship between Batch interface and BasicBatch class in the Connector API
> ----------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-169
> URL: https://jira.jboss.org/jira/browse/TEIID-169
> Project: Teiid
> Issue Type: Sub-task
> Components: Connector API
> Affects Versions: 6.0.0
> Reporter: Greg Haber
> Assignee: Steven Hawkins
> Priority: Optional
> Fix For: 6.0.0
>
>
> When a connector implements the BatchedExecution interface, it is required to implement a method nextBatch() that returns a Batch. Batch is an interface, and technically can be implemented however the connector developer wants, as long as it implements "void addRow(List row)" and "List[] getResults()" - the implementation could theoretically store the current Batch state internally in a structure that was not a List[] and just do the needed conversions in these two methods.
> However, in every known connector the implementation of BatchedExecution just uses the BasicBatch implementation we provide for Batch, which takes the straightforward path and stores the batch internally as an ArrayList.
> This best practice is not obvious from the API itself (or even from the doc) - in the legacy MetaMatrix product we have had an instance where a developer built his own implementation of Batch (and somehow ran into trouble doing so).
> Perhaps we should make this best practice more obvious - one thought is that Batch should be an abstract class rather than an interface - or perhaps BatchedExecution should require that nextBatch return BasicBatch or an extension of BasicBatch - or perhaps we should leave the API as is in this regard and just highlight this in the doc (and javadoc).
--
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