[JBoss JIRA] (TEIID-2578) add/remove schema elements
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2578?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2578:
---------------------------------------
> adminEventDistributor methods to deleteDataSources did not cross my mind, may be they should not be replicated.
That's the part I'm questioning. Since these methods are called below EventDistributor replicated methods, they will end up being called by each cluster member.
> can you elaborate this one?
There is logic in the database drop that will try to drop associated servers, but it looks like there is a shared connectormanagerrepository among all vdbs.
> add/remove schema elements
> --------------------------
>
> Key: TEIID-2578
> URL: https://issues.jboss.org/browse/TEIID-2578
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 9.2
>
>
> Schemas are currently static after load. Modifications can only happen with restarts or new versions. We should allow add/drop at runtime.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (TEIID-2578) add/remove schema elements
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2578?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2578:
-------------------------------------
DatabaseStorage is cluster aware service. See that is _SingletonPolicy_ i.e. there will be a single service of this kind in the whole cluster, any call made on this get routed to single instance on the master node. If the master node is down for some reason, this service will not be available. So, the replicated EventDistributor call is only for modifying the DatabaseStore copy.
adminEventDistributor methods to deleteDataSources did not cross my mind, may be they should not be replicated.
>Also what is the notion of server ownership on a databaseDrop?
can you elaborate this one?
> add/remove schema elements
> --------------------------
>
> Key: TEIID-2578
> URL: https://issues.jboss.org/browse/TEIID-2578
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 9.2
>
>
> Schemas are currently static after load. Modifications can only happen with restarts or new versions. We should allow add/drop at runtime.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (TEIID-4530) Add semicolons to generated ddl
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4530:
-------------------------------------
Summary: Add semicolons to generated ddl
Key: TEIID-4530
URL: https://issues.jboss.org/browse/TEIID-4530
Project: Teiid
Issue Type: Sub-task
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 9.1.1, 9.0.5
We should be generating DDL that is both forwards and backwards compatible with the TEIID-4528 change, which means that all ddl statements will need terminated with a semicolon.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (TEIID-4528) ddl generation / parsing semicolon handling
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4528?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4528.
-----------------------------------
Resolution: Done
DDL statements must now be separated by a semicolon - but we'll for now allow create table / procedure to not have a trailing delimiter. This will keep things backwards compatible with scripts generated by Teiid and Teiid Designer, but eventually we may need to remove this option. To that end, I'll backport the ddl generation changes to 9.1/9.0.
> ddl generation / parsing semicolon handling
> -------------------------------------------
>
> Key: TEIID-4528
> URL: https://issues.jboss.org/browse/TEIID-4528
> Project: Teiid
> Issue Type: Bug
> Components: Grammar, Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.2
>
>
> The DDL to string logic omits the trailing semicolon with global temp tables and create procedure statements. The parser is also lax in that it will accept multiple ddl statements without a delimiter. With the addition of new keywords / statements in TEIID-2578 this introduces ambiguities into the grammar.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (TEIID-4477) LDAP connector disconnects intermittently with error "TEIID12002"
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4477?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4477:
---------------------------------------
Thanks Jan
> LDAP connector disconnects intermittently with error "TEIID12002"
> -----------------------------------------------------------------
>
> Key: TEIID-4477
> URL: https://issues.jboss.org/browse/TEIID-4477
> Project: Teiid
> Issue Type: Bug
> Components: LDAP Connector
> Affects Versions: 8.12.5
> Environment: Red Hat JBoss Data Virtualization - Version 6.3.0
> Reporter: Rafael Coutinho
> Assignee: Steven Hawkins
> Fix For: 9.1, 9.0.5, 8.12.7.6_3
>
>
> We are using LDAP connector for virtualizing the ldap employee directory data. For some reason every 3 to 4 hours we get a connection error between JDV and LDAP.
> The exception says it could not find the context name, but after restarting it it works again.
> Here is the exception:
> 11:21:12,868 WARN [org.teiid.CONNECTOR] (Worker62_QueryProcessorQueue108177) Connector worker process failed for atomic-request=6S71mw5pkfvo.106.3.19906: org.teiid.translator.TranslatorException: TEIID12002 Failed to create LDAP search context from the specified context name ou=users,dc=redhat,dc=com. Check the table/group name in source to ensure the context exists.
> at org.teiid.translator.ldap.LDAPSyncQueryExecution.createSearchContext(LDAPSyncQueryExecution.java:148) [translator-ldap-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.translator.ldap.LDAPSyncQueryExecution.execute(LDAPSyncQueryExecution.java:130) [translator-ldap-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:364)
> at sun.reflect.GeneratedMethodAccessor184.invoke(Unknown Source) [:1.8.0-internal]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) [rt.jar:1.8.0-internal]
> at java.lang.reflect.Method.invoke(Method.java:508) [rt.jar:2.6 (07-19-2016)]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy80.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277) [rt.jar:1.8.0-internal]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0-internal]
> Caused by: javax.naming.CommunicationException: connection closed [Root exception is java.io.IOException: connection closed]; remaining name 'ou=users,dc=redhat,dc=com'
> at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2014) [rt.jar:1.8.0-internal]
> at com.sun.jndi.ldap.LdapCtx.doSearchOnce(LdapCtx.java:1945) [rt.jar:1.8.0-internal]
> at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1039) [rt.jar:1.8.0-internal]
> at com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:554) [rt.jar:1.8.0-internal]
> at com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:189) [rt.jar:1.8.0-internal]
> at com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:178) [rt.jar:1.8.0-internal]
> at javax.naming.InitialContext.lookup(InitialContext.java:428) [rt.jar:1.8.0-internal]
> at javax.naming.InitialContext.lookup(InitialContext.java:428) [rt.jar:1.8.0-internal]
> at org.teiid.resource.adapter.ldap.LDAPConnectionImpl.lookup(LDAPConnectionImpl.java:193)
> at org.teiid.translator.ldap.LDAPSyncQueryExecution.createSearchContext(LDAPSyncQueryExecution.java:146) [translator-ldap-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> ... 18 more
> Caused by: java.io.IOException: connection closed
> at com.sun.jndi.ldap.LdapClient.ensureOpen(LdapClient.java:1604) [rt.jar:1.8.0-internal]
> at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:542) [rt.jar:1.8.0-internal]
> at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1997) [rt.jar:1.8.0-internal]
> ... 27 more
> 11:21:12,871 ERROR [org.teiid.CONNECTOR] (Worker63_QueryProcessorQueue108178) null: java.lang.NullPointerException
> at org.teiid.translator.ldap.LDAPSyncQueryExecution.close(LDAPSyncQueryExecution.java:186) [translator-ldap-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.close(ConnectorWorkItem.java:255)
> at sun.reflect.GeneratedMethodAccessor185.invoke(Unknown Source) [:1.8.0-internal]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) [rt.jar:1.8.0-internal]
> at java.lang.reflect.Method.invoke(Method.java:508) [rt.jar:2.6 (07-19-2016)]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy80.close(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.fullyCloseSource(DataTierTupleSource.java:338)
> at org.teiid.dqp.internal.process.DataTierTupleSource.exceptionOccurred(DataTierTupleSource.java:394)
> at org.teiid.dqp.internal.process.DataTierTupleSource.nextTuple(DataTierTupleSource.java:161)
> at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:391)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.relational.SelectNode.nextBatchDirect(SelectNode.java:104)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:150)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.relational.DupRemoveNode.nextBatchDirect(DupRemoveNode.java:62)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:472)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0-internal]
> 11:21:12,874 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (Worker63_QueryProcessorQueue108178) LDAPSource: returnConnection(6306ef86, false) [1/20]
> 11:21:12,874 WARN [org.teiid.PROCESSOR] (Worker63_QueryProcessorQueue108178) TEIID30020 Processing exception for request 6S71mw5pkfvo.106 'TEIID30504 local: TEIID12002 Failed to create LDAP search context from the specified context name ou=users,dc=redhat,dc=com. Check the table/group name in source to ensure the context exists.'. Originally TeiidProcessingException 'connection closed' LdapClient.java:1604. Enable more detailed logging to see the entire stacktrace.
> 11:21:16,120 DEBUG [org.apache.catalina.session] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Start expire sessions StandardManager at 1474903276120 sessioncount 0
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (TEIID-4477) LDAP connector disconnects intermittently with error "TEIID12002"
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-4477?page=com.atlassian.jira.plugin... ]
Jan Stastny commented on TEIID-4477:
------------------------------------
[~shawkins] The issue has been resolved correctly. I was missing the validation and flush strategy configuration in my resource-adapter definition. With following everything is fine:
{code:xml}
<resource-adapter id="ra_inmemoryldap">
<module slot="main" id="org.jboss.teiid.resource-adapter.ldap"/>
<transaction-support>NoTransaction</transaction-support>
<connection-definitions>
<connection-definition class-name="org.teiid.resource.adapter.ldap.LDAPManagedConnectionFactory" jndi-name="java:/inmemoryldap" pool-name="ra_inmemoryldap">
<config-property name="LdapAdminUserPassword">
secret
</config-property>
<config-property name="LdapAdminUserDN">
uid=admin,ou=system
</config-property>
<config-property name="LdapTxnTimeoutInMillis">
-1
</config-property>
<config-property name="LdapUrl">
ldap://localhost:10389
</config-property>
<pool>
<flush-strategy>FailingConnectionOnly</flush-strategy>
</pool>
<validation>
<background-validation>true</background-validation>
<background-validation-millis>100</background-validation-millis>
</validation>
</connection-definition>
</connection-definitions>
</resource-adapter>
{code}
> LDAP connector disconnects intermittently with error "TEIID12002"
> -----------------------------------------------------------------
>
> Key: TEIID-4477
> URL: https://issues.jboss.org/browse/TEIID-4477
> Project: Teiid
> Issue Type: Bug
> Components: LDAP Connector
> Affects Versions: 8.12.5
> Environment: Red Hat JBoss Data Virtualization - Version 6.3.0
> Reporter: Rafael Coutinho
> Assignee: Steven Hawkins
> Fix For: 9.1, 9.0.5, 8.12.7.6_3
>
>
> We are using LDAP connector for virtualizing the ldap employee directory data. For some reason every 3 to 4 hours we get a connection error between JDV and LDAP.
> The exception says it could not find the context name, but after restarting it it works again.
> Here is the exception:
> 11:21:12,868 WARN [org.teiid.CONNECTOR] (Worker62_QueryProcessorQueue108177) Connector worker process failed for atomic-request=6S71mw5pkfvo.106.3.19906: org.teiid.translator.TranslatorException: TEIID12002 Failed to create LDAP search context from the specified context name ou=users,dc=redhat,dc=com. Check the table/group name in source to ensure the context exists.
> at org.teiid.translator.ldap.LDAPSyncQueryExecution.createSearchContext(LDAPSyncQueryExecution.java:148) [translator-ldap-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.translator.ldap.LDAPSyncQueryExecution.execute(LDAPSyncQueryExecution.java:130) [translator-ldap-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:364)
> at sun.reflect.GeneratedMethodAccessor184.invoke(Unknown Source) [:1.8.0-internal]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) [rt.jar:1.8.0-internal]
> at java.lang.reflect.Method.invoke(Method.java:508) [rt.jar:2.6 (07-19-2016)]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy80.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277) [rt.jar:1.8.0-internal]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0-internal]
> Caused by: javax.naming.CommunicationException: connection closed [Root exception is java.io.IOException: connection closed]; remaining name 'ou=users,dc=redhat,dc=com'
> at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2014) [rt.jar:1.8.0-internal]
> at com.sun.jndi.ldap.LdapCtx.doSearchOnce(LdapCtx.java:1945) [rt.jar:1.8.0-internal]
> at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1039) [rt.jar:1.8.0-internal]
> at com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:554) [rt.jar:1.8.0-internal]
> at com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:189) [rt.jar:1.8.0-internal]
> at com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:178) [rt.jar:1.8.0-internal]
> at javax.naming.InitialContext.lookup(InitialContext.java:428) [rt.jar:1.8.0-internal]
> at javax.naming.InitialContext.lookup(InitialContext.java:428) [rt.jar:1.8.0-internal]
> at org.teiid.resource.adapter.ldap.LDAPConnectionImpl.lookup(LDAPConnectionImpl.java:193)
> at org.teiid.translator.ldap.LDAPSyncQueryExecution.createSearchContext(LDAPSyncQueryExecution.java:146) [translator-ldap-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> ... 18 more
> Caused by: java.io.IOException: connection closed
> at com.sun.jndi.ldap.LdapClient.ensureOpen(LdapClient.java:1604) [rt.jar:1.8.0-internal]
> at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:542) [rt.jar:1.8.0-internal]
> at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1997) [rt.jar:1.8.0-internal]
> ... 27 more
> 11:21:12,871 ERROR [org.teiid.CONNECTOR] (Worker63_QueryProcessorQueue108178) null: java.lang.NullPointerException
> at org.teiid.translator.ldap.LDAPSyncQueryExecution.close(LDAPSyncQueryExecution.java:186) [translator-ldap-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.close(ConnectorWorkItem.java:255)
> at sun.reflect.GeneratedMethodAccessor185.invoke(Unknown Source) [:1.8.0-internal]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) [rt.jar:1.8.0-internal]
> at java.lang.reflect.Method.invoke(Method.java:508) [rt.jar:2.6 (07-19-2016)]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy80.close(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.fullyCloseSource(DataTierTupleSource.java:338)
> at org.teiid.dqp.internal.process.DataTierTupleSource.exceptionOccurred(DataTierTupleSource.java:394)
> at org.teiid.dqp.internal.process.DataTierTupleSource.nextTuple(DataTierTupleSource.java:161)
> at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:391)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.relational.SelectNode.nextBatchDirect(SelectNode.java:104)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:150)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.relational.DupRemoveNode.nextBatchDirect(DupRemoveNode.java:62)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:472)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0-internal]
> 11:21:12,874 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (Worker63_QueryProcessorQueue108178) LDAPSource: returnConnection(6306ef86, false) [1/20]
> 11:21:12,874 WARN [org.teiid.PROCESSOR] (Worker63_QueryProcessorQueue108178) TEIID30020 Processing exception for request 6S71mw5pkfvo.106 'TEIID30504 local: TEIID12002 Failed to create LDAP search context from the specified context name ou=users,dc=redhat,dc=com. Check the table/group name in source to ensure the context exists.'. Originally TeiidProcessingException 'connection closed' LdapClient.java:1604. Enable more detailed logging to see the entire stacktrace.
> 11:21:16,120 DEBUG [org.apache.catalina.session] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Start expire sessions StandardManager at 1474903276120 sessioncount 0
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (TEIID-4529) Remove the dynamic vdb terminology
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4529:
-------------------------------------
Summary: Remove the dynamic vdb terminology
Key: TEIID-4529
URL: https://issues.jboss.org/browse/TEIID-4529
Project: Teiid
Issue Type: Quality Risk
Components: Documentation
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 9.0
We should remove/deprecate the dynamic term and instead reference native metadata import and ddl - soon tooling will provide vdbs defined with ddl and the dynamic differentiation won't be needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (TEIID-4366) Provide CORS support on OData Service
by Juraj Duráni (JIRA)
[ https://issues.jboss.org/browse/TEIID-4366?page=com.atlassian.jira.plugin... ]
Juraj Duráni reopened TEIID-4366:
---------------------------------
Teiid returns _TEIID16056_ even for requests with "Origin" header.
{code:java|title=Sample code}
String origin = "http://localhost";
HttpURLConnection con = (HttpURLConnection) new URL("http://localhost:8080/odata4/my_vdb/views/v1").openConnection();
con.setRequestProperty("Authorization", "Basic " + Base64.encodeBase64String("user:user".getBytes()));
con.setRequestProperty("Origin", origin);
con.setRequestMethod("OPTIONS");
con.connect();
try{
int code = con.getResponseCode();
Assert.assertEquals(code, HttpStatus.SC_NO_CONTENT, "Response code.");
...
} finally {
con.disconnect();
}
{code}
{code:plain|title=Test result}
java.lang.AssertionError: Response code. expected [204] but found [400]
{code}
> Provide CORS support on OData Service
> -------------------------------------
>
> Key: TEIID-4366
> URL: https://issues.jboss.org/browse/TEIID-4366
> Project: Teiid
> Issue Type: Enhancement
> Components: OData
> Affects Versions: 8.12
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: Alpha3
> Fix For: 9.1, 9.0.4, 8.12.7.6_3
>
>
> Good write up CORS can be found here https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
> OData needs to implement CORS support to be valuable with java script based client development technologies.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months