[JBoss JIRA] (TEIID-4389) Local connection waits for active VDB 1, 000, 000 times longer than specified in waitForLoad property
by Juraj Duráni (JIRA)
Juraj Duráni created TEIID-4389:
-----------------------------------
Summary: Local connection waits for active VDB 1,000,000 times longer than specified in waitForLoad property
Key: TEIID-4389
URL: https://issues.jboss.org/browse/TEIID-4389
Project: Teiid
Issue Type: Bug
Reporter: Juraj Duráni
Assignee: Steven Hawkins
If user specifies waitForLoad connection property in URL, Teiid waits for longer time than specified in the property.
I believe it is because you call Object.wait(long) method with wrong parameter \[1\]. In combination with TEIID-4388, from users point of view, local connection waits for active VDB for ever.
\[1\] See this [commit|https://github.com/teiid/teiid/commit/d7e161ff04c77f8f2da85b2debb1...]. You call method like _vdb.wait(timeOutNanos);_, but from javadoc: *timeout - the maximum time to wait in milliseconds.* It means that Teiid waits 1,000,000 times longer than specified in parameter.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-4389) Local connection waits for active VDB 1, 000, 000 times longer than specified in waitForLoad property
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4389?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-4389:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1367652
Bugzilla Update: Perform
> Local connection waits for active VDB 1,000,000 times longer than specified in waitForLoad property
> ---------------------------------------------------------------------------------------------------
>
> Key: TEIID-4389
> URL: https://issues.jboss.org/browse/TEIID-4389
> Project: Teiid
> Issue Type: Bug
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> If user specifies waitForLoad connection property in URL, Teiid waits for longer time than specified in the property.
> I believe it is because you call Object.wait(long) method with wrong parameter \[1\]. In combination with TEIID-4388, from users point of view, local connection waits for active VDB for ever.
> \[1\] See this [commit|https://github.com/teiid/teiid/commit/d7e161ff04c77f8f2da85b2debb1...]. You call method like _vdb.wait(timeOutNanos);_, but from javadoc: *timeout - the maximum time to wait in milliseconds.* It means that Teiid waits 1,000,000 times longer than specified in parameter.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-4388) If model fails to load native metadata, VDB has still status LOADING
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4388?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-4388:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1367644
Bugzilla Update: Perform
> If model fails to load native metadata, VDB has still status LOADING
> --------------------------------------------------------------------
>
> Key: TEIID-4388
> URL: https://issues.jboss.org/browse/TEIID-4388
> Project: Teiid
> Issue Type: Bug
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> If one model fails to load native metadata, VDB's status is still LOADING.
> {code:plain|title=CLI status}
> [standalone@localhost:9999 /] /subsystem=teiid:get-vdb(vdb-name=test,vdb-version=1)
> {
> "outcome" => "success",
> "result" => {
> "vdb-name" => "test",
> "status" => "LOADING",
> "vdb-version" => 1,
> ...
> "models" => [
> {
> "model-name" => "Source1",
> ...
> "metadata-status" => "LOADED"
> },
> {
> "model-name" => "Source2",
> ...
> "validity-errors" => [
> {
> "severity" => "INFO",
> "message" => "TEIID50029 VDB test.1 model \"Source2\" metadata is currently being loaded. Start Time: 8/17/16 7:41 AM"
> },
> {
> "severity" => "ERROR",
> "message" => "TEIID31178 Could not obtain connection for schema Source2, but one is required for metadata load. "
> }
> ],
> ...
> "metadata-status" => "FAILED"
> },
> {
> "model-name" => "Source3",
> ...
> "metadata-status" => "LOADED"
> }
> ]
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-4388) If model fails to load native metadata, VDB has still status LOADING
by Juraj Duráni (JIRA)
Juraj Duráni created TEIID-4388:
-----------------------------------
Summary: If model fails to load native metadata, VDB has still status LOADING
Key: TEIID-4388
URL: https://issues.jboss.org/browse/TEIID-4388
Project: Teiid
Issue Type: Bug
Reporter: Juraj Duráni
Assignee: Steven Hawkins
If one model fails to load native metadata, VDB's status is still LOADING.
{code:plain|title=CLI status}
[standalone@localhost:9999 /] /subsystem=teiid:get-vdb(vdb-name=test,vdb-version=1)
{
"outcome" => "success",
"result" => {
"vdb-name" => "test",
"status" => "LOADING",
"vdb-version" => 1,
...
"models" => [
{
"model-name" => "Source1",
...
"metadata-status" => "LOADED"
},
{
"model-name" => "Source2",
...
"validity-errors" => [
{
"severity" => "INFO",
"message" => "TEIID50029 VDB test.1 model \"Source2\" metadata is currently being loaded. Start Time: 8/17/16 7:41 AM"
},
{
"severity" => "ERROR",
"message" => "TEIID31178 Could not obtain connection for schema Source2, but one is required for metadata load. "
}
],
...
"metadata-status" => "FAILED"
},
{
"model-name" => "Source3",
...
"metadata-status" => "LOADED"
}
]
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-4374) Procedure missing for an OData metadata request to a Swagger VDB
by Van Dillon (JIRA)
[ https://issues.jboss.org/browse/TEIID-4374?page=com.atlassian.jira.plugin... ]
Van Dillon commented on TEIID-4374:
-----------------------------------
Thanks for the clarification.
> Procedure missing for an OData metadata request to a Swagger VDB
> ----------------------------------------------------------------
>
> Key: TEIID-4374
> URL: https://issues.jboss.org/browse/TEIID-4374
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 9.0, 9.0.1, 9.0.2
> Environment: Windows 10 Pro x64
> Java 8
> Reporter: Van Dillon
> Assignee: Ramesh Reddy
> Labels: Beta1
> Fix For: 9.1
>
> Attachments: resource-adapter-rhq.xml, rhq-metadata.xml, rhq-vdb.xml, swagger.json
>
>
> When a REST PUT path defined in Swagger has a path parameter and a body it does not appear in OData metadata.
> See the attached swagger.json for an example. The operation 'executeOperation' does not appear in OData metadata.
> The code that determines if a procedure is allowed is in:
> org.teiid.olingo.service.ODataSchemaBuilder.allowedProcedure()
> The comment seems to indicate that as long as there is only a single LOB, multiple 'in' parameters are allowed. But the actual code does not allow any other 'in' parameters if there is a LOB parameter.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-4387) Issues with $it support
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4387:
-------------------------------------
Summary: Issues with $it support
Key: TEIID-4387
URL: https://issues.jboss.org/browse/TEIID-4387
Project: Teiid
Issue Type: Bug
Components: OData
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 9.1
Only a single $it reference can exist with the current logic, and it can only be used in a filter. With the refactoring to array style logic, we should be able to expand its usage.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-4100) Full odata expand support
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4100?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4100.
-----------------------------------
Resolution: Done
The initial work has been completed.
Follow on tasks:
- support level
- remove the isSameEntity logic - which is only needed for the $it construct
- create an rewrite optimization to turn a single expand into a left outer join, which will preserve the performance characteristics of the old logic
> Full odata expand support
> -------------------------
>
> Key: TEIID-4100
> URL: https://issues.jboss.org/browse/TEIID-4100
> Project: Teiid
> Issue Type: Feature Request
> Components: OData
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.1
>
>
> To move TEIID-3039 we need to have xml document model style processing for expand support. That is top down generation that supports arbitrary descendants - with targeted optimizations for projection minimization and dependent joins.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-3511) usage of BITAND function in exists statement results in duplicate rows
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3511?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3511.
-----------------------------------
Resolution: Out of Date
Thanks Bram. Resolving as out of date.
> usage of BITAND function in exists statement results in duplicate rows
> ----------------------------------------------------------------------
>
> Key: TEIID-3511
> URL: https://issues.jboss.org/browse/TEIID-3511
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.9.1
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
> Attachments: debugplan_bitand.txt, debugplan_bitand_correct.txt, debugplan_nobitand.txt, debugplan_nobitand_correct.txt
>
>
> I've added the debug plan for the query without the BITAND function and with the BITAND function as an attachment.
> The version without the BITAND function returns 438 rows and the version with BITAND function returns 833 rows. I can see however that rows are duplicated in this second result. I've checked this by executing the version with BITAND statement with select *.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-4385) Nested subquery in an aggregate fails to evaluate
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4385?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4385.
-----------------------------------
Resolution: Done
Updated the logic to look below the grouping node for the current correlation groups.
> Nested subquery in an aggregate fails to evaluate
> -------------------------------------------------
>
> Key: TEIID-4385
> URL: https://issues.jboss.org/browse/TEIID-4385
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.12
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.1, 9.0.3
>
>
> A correlated subquery that appears in an aggregate value inside of a subquery, will not have the correlated values available and fail with a TEIID30328 exception.
> For example:
> SELECT g0.a, g0.b, (SELECT max((SELECT g2.a FROM m.z AS g2 WHERE g2.b = g1.a)) FROM m.y AS g1 WHERE g0.a = g1.b) FROM m.x AS g0
> will fail on the g0.a reference.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-4386) Vertica Translator - Missing Quotes on Reserved Words.
by Ted Jones (JIRA)
[ https://issues.jboss.org/browse/TEIID-4386?page=com.atlassian.jira.plugin... ]
Ted Jones updated TEIID-4386:
-----------------------------
Summary: Vertica Translator - Missing Quotes on Reserved Words. (was: Vertica Translator - Missing Quote on reserved word.)
> Vertica Translator - Missing Quotes on Reserved Words.
> ------------------------------------------------------
>
> Key: TEIID-4386
> URL: https://issues.jboss.org/browse/TEIID-4386
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 9.0.2
> Reporter: Ted Jones
> Assignee: Steven Hawkins
> Attachments: firstError.txt
>
>
> Previewing a Vertica table results in the following error:
> 10:46:53,873 WARN [org.teiid.RUNTIME] (teiid-async-threads - 1) TEIID50036 VDB PREVIEW-7288da00-a070-45c9-9762-671d641ed431.1 model "rhel_iot_data" metadata failed to load. Reason:TEIID30386 org.teiid.api.exception.query.QueryParserException: TEIID31100 Parsing error: Encountered "'Integer'), [*]date[*] date OPTIONS" at line 5, column 9.
> Was expecting: "constraint" | "foreign" | "primary" | "unique" | id: org.teiid.metadata.ParseException: TEIID30386 org.teiid.api.exception.query.QueryParserException: TEIID31100 Parsing error: Encountered "'Integer'), [*]date[*] date OPTIONS" at line 5, column 9.
> Was expecting: "constraint" | "foreign" | "primary" | "unique" | id
> at org.teiid.query.parser.QueryParser.parseDDL(QueryParser.java:472) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.metadata.MetadataFactory.parse(MetadataFactory.java:768) [teiid-api-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.metadata.DDLMetadataRepository.loadMetadata(DDLMetadataRepository.java:40) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.runtime.AbstractVDBDeployer$MetadataRepositoryWrapper.loadMetadata(AbstractVDBDeployer.java:84) [teiid-runtime-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.jboss.VDBService$6.run(VDBService.java:395) [teiid-jboss-integration-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at org.teiid.jboss.VDBService$7.run(VDBService.java:446) [teiid-jboss-integration-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_65]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: org.teiid.api.exception.query.QueryParserException: TEIID31100 Parsing error: Encountered "'Integer'), [*]date[*] date OPTIONS" at line 5, column 9.
> Was expecting: "constraint" | "foreign" | "primary" | "unique" | id
> at org.teiid.query.parser.QueryParser.convertParserException(QueryParser.java:214) [teiid-engine-8.12.5.redhat-8.jar:8.12.5.redhat-8]
> ... 11 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months