January 2019 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5522) Avoid pushing join to datasource if DS cannot handle 1600+ columns

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5522?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5522: ---------------------------------- Fix Version/s: 12.1 (was: 12.x) > Avoid pushing join to datasource if DS cannot handle 1600+ columns > ------------------------------------------------------------------- > > Key: TEIID-5522 > URL: https://issues.jboss.org/browse/TEIID-5522 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors, Query Engine > Reporter: Norbert Funke > Priority: Major > Fix For: 12.1 > > > Problem: I am trying to create a wide view (~5000 columns), which works across data sources fine JDV. However, when I try to create the view with a join on 2+ table from data source, the optimizer pushes down the join to the source. The current source cannot handle more then ~1600 columns. > Example: When trying to join Member_DX1 and Member_DX2 at client, JDV pushes the enter code herecombined join to postgres as one getting the too max column error. > /* TABLE 1 */ > CREATE VIEW Member_DX1 ( > MEMB_BID Integer > , DX130402000000 Integer > , DX180608000000 Integer > , DX20401070000 Integer > .... /* 1000 more */ > as > SELECT dx.memb_bid > , case dx.EPI_1_DX4 when 130402000000 then 1 else 0 END as DX130402000000 > , case dx.EPI_1_DX4 when 180608000000 then 1 else 0 END as DX180608000000 > , case dx.EPI_1_DX4 when 20401070000 then 1 else 0 END as DX20401070000 > ... > FROM BDR.ENH_EPI_DETAIL dx > /* TABLE 2 */ > CREATE VIEW Member_DX2 ( > MEMB_BID Integer > , DX200102010000 Integer > , DX90125000000 Integer > , DX160603070000 Integer > ... /* 1000 more ... > SELECT dx.memb_bid /* FOREIGN TABLE */ > , case dx.EPI_1_DX4 when 200102010000 then 1 else 0 END as DX200102010000 > , case dx.EPI_1_DX4 when 90125000000 then 1 else 0 END as DX90125000000 > , case dx.EPI_1_DX4 when 160603070000 then 1 else 0 END as DX160603070000 > ...`enter code here` > FROM BDR.ENH_EPI_DETAIL dx; > then my query in (e.g. dBeaver) looks like this: > SELECT * from Member_DX1 dx1 > join Member_DX2 dx2 > on dx1.MEMB_BID = dx2.MEMB_BID -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5618) clientHostName always reported as localhost via JDBC connection

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5618?page=com.atlassian.jira.plugin... ] Work on TEIID-5618 started by Steven Hawkins. --------------------------------------------- > clientHostName always reported as localhost via JDBC connection > --------------------------------------------------------------- > > Key: TEIID-5618 > URL: https://issues.jboss.org/browse/TEIID-5618 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 8.12.16.6_4 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Priority: Major > > VDB session information in the Management Console and logs shows localhost for Client Host Name with a JDBC connection. > Client Host Name: localhost > Client Hardware Address: 4CBB58502284 > IP Address: > Security Domain: teiid-security > In the server.log with org.teiid set to TRACE it displays below for session: > DEBUG [org.teiid.SECURITY] (New I/O worker #2) Logon successful, created session: sessionid=DW9hzUw5P1ob; userName=teiidUser@teiid-security; vdbName=deb_pg; vdbVersion=2; createdTime=Thu Jan 17 08:15:44 CST 2019; applicationName=JDBC; clientHostName=localhost; clientHardwareAddress=4CBB58502284; IPAddress=192.168.x.x; securityDomain=teiid-security; lastPingTime=Thu Jan 17 08:15:44 CST 2019 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5623) Review open shift cpu and threading assumptions

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5623: ------------------------------------- Summary: Review open shift cpu and threading assumptions Key: TEIID-5623 URL: https://issues.jboss.org/browse/TEIID-5623 Project: Teiid Issue Type: Quality Risk Components: Server Reporter: Steven Hawkins Assignee: Ramesh Reddy Fix For: 12.x It also needs to be validated that we're correlating max active plans and connection pool sizings with the cpu limits set on our images. Our default of 20 max active plans has been based upon performance primarily with dual / quad systems w / hyper threading. I'm not sure how well this correlates to the virtual cpu limit. Also we're using the available cpus setting to determine thread availability for sockets - so that may be unnecessarily overly constrained. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5620) Provide flattened jmx metrics

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5620?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5620: --------------------------------------- We may need to also expose connection pool metrics - or see if there is dynamic adjustment possible. It hasn't been discussed much about what the default sizing will be. Ideally there would be a non-blocking connection pool available - it sounds like there may be something coming out of the mp effort... > Provide flattened jmx metrics > ----------------------------- > > Key: TEIID-5620 > URL: https://issues.jboss.org/browse/TEIID-5620 > Project: Teiid > Issue Type: Quality Risk > Components: Server > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.1 > > > Providing JMX metrics via jolokia to Prometheus does not work well with complex types. We are providing several metric sets - engine stats, worker pool stats, requests, etc. as beans which needs to be flattened. Simple parameters are ok to the metrics methods, but simple results are required. > We need to make sure that at least statistics are available on: > * number of plans waiting to be processed - this will be a primary metric for determining horizontal scale out > * amount /%of buffer memory used - this will be a primary metric for determining if pods need to be allocated with more memory/disk > Ideally alerting could be available on percent utilization - but we could also add a metric such as out of disk count to provide a hard count of exceptional conditions. > It's assumed that cpu utilization will be monitored from the pod itself - which will be a primary metric for determining if pods should be allocated with more cpu resources. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5622) Capture missing features from Teiid JDBC with the pg protocol

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5622: ------------------------------------- Summary: Capture missing features from Teiid JDBC with the pg protocol Key: TEIID-5622 URL: https://issues.jboss.org/browse/TEIID-5622 Project: Teiid Issue Type: Quality Risk Components: JDBC Driver Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 12.x We need to start spawning issues for missing features and known compatibility issues between Teiid JDBC and using the pg protocol - primarily with pg JDBC. This includes: * lob support - lo is not yet implemented in pg, just inlining TEIID-1163 * xa support - TEIID-4012 * query plan handling - TEIID-5527 * determine if reauthentication is supported * domain type reporting - TEIID-4909 * typing differences in general - should there be a mode where we can report teiid type names? that's likely not possible as many pg clients have builtin logic around the standard types * multi-dimensional arrays * like escape and other pg behavior that have workarounds in Teiid * generated keys - we only return a 0 oid for inserts - what about upserts? -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5622) Capture missing features/issues from Teiid JDBC with the pg protocol

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5622?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5622: ---------------------------------- Summary: Capture missing features/issues from Teiid JDBC with the pg protocol (was: Capture missing features from Teiid JDBC with the pg protocol) > Capture missing features/issues from Teiid JDBC with the pg protocol > -------------------------------------------------------------------- > > Key: TEIID-5622 > URL: https://issues.jboss.org/browse/TEIID-5622 > Project: Teiid > Issue Type: Quality Risk > Components: JDBC Driver > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.x > > > We need to start spawning issues for missing features and known compatibility issues between Teiid JDBC and using the pg protocol - primarily with pg JDBC. > This includes: > * lob support - lo is not yet implemented in pg, just inlining TEIID-1163 > * xa support - TEIID-4012 > * query plan handling - TEIID-5527 > * determine if reauthentication is supported > * domain type reporting - TEIID-4909 > * typing differences in general - should there be a mode where we can report teiid type names? that's likely not possible as many pg clients have builtin logic around the standard types > * multi-dimensional arrays > * like escape and other pg behavior that have workarounds in Teiid > * generated keys - we only return a 0 oid for inserts - what about upserts? -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5615) Error when binding NULL to nullable parameter in a prepared statement with PDO PostgreSQL ODBC client

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5615?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5615. ----------------------------------- Fix Version/s: 12.1 11.2.2 12.0.1 Resolution: Done Your temporary fix is the correct one. Null bindings are specified with a length of -1. > Error when binding NULL to nullable parameter in a prepared statement with PDO PostgreSQL ODBC client > ----------------------------------------------------------------------------------------------------- > > Key: TEIID-5615 > URL: https://issues.jboss.org/browse/TEIID-5615 > Project: Teiid > Issue Type: Bug > Components: ODBC > Affects Versions: 11.0, 11.2 > Environment: All infrastructure is Dockerized on Windows 64bit (see below) > WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final) > Teiid Engine 11.2.0 > DatabaseProductVersion=11.1 (Debian 11.1-1.pgdg90+1) > PostgreSQL JDBC Driver=42.2.5 > PDO Driver for PostgreSQL (from phpinfo()) > PostgreSQL(libpq) Version: 9.6.10 > Module version: 7.1.26 > Reporter: George Ushakov > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.1, 11.2.2, 12.0.1 > > > On Teiid 11.0 (and probably later versions, as well) running in a WildFly there is a problem when binding to a NULLABLE parameter in a prepared statement with NULL value when running against a PostgreSQL source from a PDO (PHP) ODBC client. > PDO calls causing the error are related to [PDOStatement::bindValue|https://secure.php.net/manual/en/pdostatement.bin...] > and [PDOStatement::bindParam|https://secure.php.net/manual/en/pdostatement.bin...]. > It occurs exclusively when the client is trying to bind a NULL value (corresponding to a NULLABLE column in a table) to the prepared statement using PDO::PARAM_NULL type. > Example PHP code > {code:php} > $dbh = new PDO('pgsql:host=<teiid_host>;port=35432;dbname=<vdb_name>;user=<teiid_user>;password=<teiid_password>'); > $stmt = $dbh->prepare("INSERT INTO foobar (id, optional) VALUES(?, ?)"); > $stmt->bindValue(1, 1); > $stmt->bindValue(2, null, PDO::PARAM_NULL); > $stmt->execute(); > {code} > Exception thrown is > Caused by: java.lang.NegativeArraySizeException > at org.teiid.transport.PgFrontendProtocol.createByteArray(PgFrontendProtocol.java:328) > at org.teiid.transport.PgFrontendProtocol.buildBind(PgFrontendProtocol.java:266) > at org.teiid.transport.PgFrontendProtocol.createRequestMessage(PgFrontendProtocol.java:153) > at org.teiid.transport.PgFrontendProtocol.decode(PgFrontendProtocol.java:133) > at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) > ... 15 more -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5621) Provide rest access with SpringBoot

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5621: ------------------------------------- Summary: Provide rest access with SpringBoot Key: TEIID-5621 URL: https://issues.jboss.org/browse/TEIID-5621 Project: Teiid Issue Type: Feature Request Components: Teiid Spring Boot Reporter: Steven Hawkins Assignee: Ramesh Reddy The current rest access layer is based upon the generation of a war with deployment hooks in wildfly. There should be a build-time or similar mechanism to expose rest with spring boot. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5555) Create OpenAPI (swagger) metadata document based on OData

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5555?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5555: ---------------------------------- Fix Version/s: (was: 11.2.2) > Create OpenAPI (swagger) metadata document based on OData > --------------------------------------------------------- > > Key: TEIID-5555 > URL: https://issues.jboss.org/browse/TEIID-5555 > Project: Teiid > Issue Type: Enhancement > Components: OData > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Priority: Critical > Fix For: 12.1 > > > Automatically generate Swagger metadata document based on OData metadata such the tools like 3Scale can understand the metadata through existing plugins until OData specific plugin is generated. Only swagger 2.0 document is considered for now. 3.0 support is not considered. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5620) Provide flattened jmx metrics

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5620: ------------------------------------- Summary: Provide flattened jmx metrics Key: TEIID-5620 URL: https://issues.jboss.org/browse/TEIID-5620 Project: Teiid Issue Type: Quality Risk Components: Server Reporter: Steven Hawkins Assignee: Steven Hawkins Providing JMX metrics via jolokia to Prometheus does not work well with complex types. We are providing several metric sets - engine stats, worker pool stats, requests, etc. as beans which needs to be flattened. Simple parameters are ok to the metrics methods, but simple results are required. We need to make sure that at least statistics are available on: * number of plans waiting to be processed - this will be a primary metric for determining horizontal scale out * amount /%of buffer memory used - this will be a primary metric for determining if pods need to be allocated with more memory/disk Ideally alerting could be available on percent utilization - but we could also add a metric such as out of disk count to provide a hard count of exceptional conditions. It's assumed that cpu utilization will be monitored from the pod itself - which will be a primary metric for determining if pods should be allocated with more cpu resources. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues January 2019